FED Process 1.3.1

The FED (Front End Development) Process framework takes advantage of the object oriented design approach from MooTools and applies it to the entire scope of front end development.

Using the file structure and build tools provided with the download, you will be able to start building webpages very quickly and efficiently. FED Process is also built to be highly maintainable so that even if you have many pages, you would still be able to locate your JavaScript or CSS resources easily.

NEW (2011/AUG/15) - 1.3.1 supports MooTools 1.3, has a bunch of fixes and bundled with new LazyLoader.


David Chan
Current version
GitHub Issues



  • _self_/_current_:
    • core/1.3.2: '*'
    • more/ [Utilities.Assets]
    • core/1.3: '*'
    • more/1.3.1: [Utilities.Assets]
    • more/1.3.1: [Class.Refactor]
    • Core/Element.Dimensions
    • Core/Fx.Tween
    • Core/Fx.Transitions
    • More/Locale
    • Picker
    • Core/Element.Event
    • Picker.Attach
    • Locale.en-US.DatePicker
    • More/Date
    • Picker.Date

How to use

  1. Download and install Apache ANT 1.8.0. You'll need to set up your system's environment PATH variable to allow running "ant" anywhere.
  2. Download the latest version of ANT-Contrib. Extract the content and copy ant-contrib-1.0*.jar into your ant/lib/ folder.
  3. Open a shell and cd into Source/resources/main/j/n/library/
  4. Untar mootools.tgz content into same directory (tar xvzf mootools.tgz).
  5. Change directory to source/resources/main/
  6. Run: ant build-full
  7. Test the page on your browser.
  8. If you see some alert boxes, then you are all set!

How It Works

Traditionally, web developers would include every JavaScript files with script tags or they would write all their code into a single large JavaScript file. However, developing with this pattern often result in hard to read spaghetti code especially if they do not follow an object oriented approach.

With MooTools' object oriented approach however, the framework empowers code separation. That means you can easily break classes into its own files for a much better decoupling of functionality/widget. By applying a good code design, a loosely coupled MooTools class allows your code to be a lot more re-usable. Furthermore, you can package them easier and release them onto the Forge. The only problem is that including each of these classes in its own script tag could cause some performance issues on the front end. Primarily, there would be unnecessary http request for files.

Using a build process, we can keep our code separated while at the same time, packaging all these files into a single script.js would remedy the issue of having the page to make too many http requests. With the FED Process's approach, we've been able to achieve a high re-usability rate of our widgets and a great compression scheme using a minifier such as the YUI Compressor in conjunction of a server-side compressor such as GZIP.

Now the way you would work with this FED Process framework is as follows: You code your html as you would, however, the body id is key. Each page requires a unique body id to enable page-specific JavaScript. The body id tells the process which Page class to run. So for example, on your homepage, you would use a body id of "hom", the process would automatically look for Page.Hom.js which extends Page.js and would execute ONLY the code inside of Page.Hom.js. This allows your code to be very clean and efficient in the sense that other pages' class would not execute. Now inside of your Page.Hom.js, you will instantiate all the widgets classes that you need. So let's say you want to run a lightbox widget on the homepage only, then you would instantiate lightbox inside of Page.Hom.js.

Following such a process would make your life much easier in the long run when your site starts to get heavy on functionality. Another advantage is that it will allow for a friendly and painless multi-collaborator environment. When using SVN or GIT, we almost never run into code conflicts because all the files are so clearly separated. Since the code is built into the /b (build) folder, the build process actually cleans out the /b folder every time. So any conflict in the b/ folder can be ignored.

In some of our test cases and actual production work, we have more than 9000 lines of code without a single conflict when using this process. We believe that releasing our FED Process will help MooTools developers to take advantage of the object oriented nature of MooTools while adding Forge plug-ins into their own projects would be effortless. This is a tried and true development process that is stable and used everyday within our team. If you have any suggestions, then please feel free to let us know at david.chan@reol.com

Technologies Used

  1. MooTools: The JavaScript framework we all love. Of course this is used here!
  2. YUI Compressor: The same compressor used to minify your favourite JS framework.
  3. Apache ANT: Requires version 1.8.0. This tool, generally used in Java Development, plays a big role here to allow cross platform builds.
  4. ANT Contrib: Allows for some advanced features within Apache ANT such as loops.

File Structure

This will seem like overkill at first, but contributes to the maintainability of the process.

  /pages: Your static html pages lives here
  /resources: JavaScript, CSS and images
    /bin: YUI Compressor lives here
    /main: This is your module, feel free to add more
      /build.xml: This tells ANT how to build your resources, per module basis.
      /c: CSS Folder
        /n: Non Minified CSS source
          /b: Built source
          /widgets: Contains CSS classes that represent a widget
          disclaimer.css: Legal mumbo-jumbo
          global.css: Globally used CSS classes such as .clear
          ie.css: All IE specific CSS rules
          ie7.css: Only for IE7
          layout.css: CSS classes for main layout elements
          pages.css: Page specific CSS classes
        /y: Minified CSS source
          /b: Built and minified source
      /i: Images Folder
        /l: contains layout specific images
        /p: contains page specific images
          /body-id: contains a single page specific images
        /w: contains re-usable widget specific images
      /j: JavaScript Folder
        /b: Built source
        /core: Utility and System classes
        /widgets: Functionality classes
        /ext: Externally loaded classes
        /mixins: Implementable classes
        /native: Extended Native classes
        /tp: Third party classes
        disclaimer.js: Legal mumbo-jumbo
        global.js: Global variables
        global.dev.js: Global variables for your local development environment
        main.js: Entry point of your JS application

Page Development Workflow

  1. Create a html page under pages/main/
  2. Assign a unique body id. Our convention is using a three letter combination. The choice is yours.
  3. Create a page subclass under resources/main/j/n/core/Page/. Follow the pattern of the demo files.
  4. Copy the source from another demo page subclass. Don't forget to re-assign to the correct body id. Ex: if your body id is "bob", your class will be "Page.Bob"
  5. Write some test code. ex: alert('hello world');
  6. Open a command prompt or terminal and change directory to /source/resources/main/
  7. Run: ant concat-only
  8. Test your page.

Page Styling Workflow

  1. The folders of interest are resources/c/n (css source) AND resources/i/ (images)
  2. Consult the File Structure section of this README for more information for the role of each folder and file.
  3. Write your CSS.
  4. Run: ant concat-only
  5. Test your page.

Widget Development Workflow

  1. Create a new MooTools class under resources/main/j/n/widgets/ OR /resources/main/j/n/ext/ (if it's lazy loaded)
  2. If you have CSS associated to that widget, create a new CSS file under resources/main/c/n/widgets/
  3. Follow the Dummy.js / w_dummy.css pattern.
  4. Write your code.
  5. Run: ant concat-only
  6. Test your widget.

Production Workflow

  1. If you are working with multiple collaborators, then make sure you update your local repository before your push.
  2. Run: ant build-full
  3. Commit


Do not ever develop under any b/ folder. Running an ANT build would result in complete overwrite of the b/ folders. Note that any changes to JavaScript or CSS resources require an ANT build, this should become second nature.

Ant Build Syntax

  1. ant - This will perform a concatenation of all your sources into one file. This operation is very fast and used for local development and testing.
  2. ant build-full - This will perform the basic ant task and then run the minify process on all concatenated files. This will take more time and it is used for production deployment.

Release Notes

  • 1.3.1 : Fixes and support for MooTools 1.3. Bundled with new LazyLoader (also available in the Forge).
  • 1.1 : Updated LazyLoader, view documentation for this plug-in.
  • 1.0 : First stable release. Now includes demos.
  • 0.9 : Pre-release.

Future Release

A website is being build for this front end framework. Look for it in the coming months.

We will soon add in more demo test cases to better illustrate the process.

Even though the current version is stable, we strive for continuous improvements to our standards and processes. If you have any suggestions, please feel free to let us know at david.chan@reol.com


A note on comments here: These comments are moderated. No comments will show up until they are approved. Comments that are not productive (i.e. inflammatory, rude, etc) will not be approved.

Found a bug in this plugin? Please report it this repository's Github Issues.

blog comments powered by Disqus