Sorry, but I'm going to be very harsh.

I think you might have a problem here, for I completely fail to understand what this library does. It looks like a mishmash of some functionality you need for your website, packaged as a “library”. But a library is supposed to be an encapsulated piece of functionality—in your case, it looks very specific to your app—moreover, the abstractions look very much messed up.

I have literally no idea what this code does, no matter how long I look:

    // get library elements for each module
    $P.getLibElements = function (lib_hold, lib_global) {
        var list;

        // iterate through each module
        $A.someKey($R.Classes, function (val) {
            list = val[lib_hold];
            if (list) {

                // iterate through the module's l_hold properties
                $A.someKey(list, function (val, key) {
                    list[key] = lib_global(val);
                });
            }
        });
    };

    // initialize each module by property
    $P.initByProperty = function (prop) {

        // iterate through each module
        $A.someKey($R.Classes, function (val) {

            // if the property exists execute it
            if (val[prop]) {
                val[prop]();
            }
        });
    };

This is very cryptic too:

                   // turn off ajax animation
                    if (wait_animation) {
                        wait_animation.style.opacity = 0;
                    }

                    // if the server want to talk it will prefix its message with |D|, and continue
                    // normal comms with an |A|
                    if (pass_prefix === '|D|') {
                        message = pipe_string_receive.match(/^(\|D\|)([\s\S]*)(\|A\|)/);
                        $A.log('|D|FROM SERVER|');
                        $A.log(message[2]);

                        // remove the debug message
                        pipe_string_receive = pipe_string_receive.slice((message[1] + message[2]).length);

                        // this should always be an |A|, update
                        pass_prefix = pipe_string_receive.slice(0, 3);
                    }
                    if (pass_prefix === '|A|') {
                        $R.time('middle');
                        pipe = JSON.parse(pipe_string_receive.slice(3));

                        // if post exists run it
                        if ($R.Classes[pipe.model].hasOwnProperty("post")) {
                            pipe = $R.Classes[pipe.model].post(pipe);

                            // record timing information for pre(), transit, and post()
                            times = $R.time('finish');
                            pipe.time.pre = times[0];
                            pipe.time.transit = times[1];
                            pipe.time.post = times[2];
                            $A.Reg.set('pipe_post', pipe);
                        } else {
                            return;
                        }
                    } else {
                        throw "<No '|A|' or '|D|'>" + pipe_string_receive;
                    }


Or this:

    $P.definePipe = function (obj) {
        $R.packet_hold = obj;
    };

So simple, yet I have no idea why assigning some object to a property called `packet_hold` in “private namespace” somehow makes this object a pipe.

The comments don't help because apparently **they were written for someone who already understands the system**. That's an unfortunate assumption to make.


So it is both

* a poor man's JS OOP emulation layer (do you really need another one?);
* a poor man's `require.js`;
* some kind of state machine;
* some kind of piping;
* using AJAX and doing something with UI and animation?

The usage example doesn't clarify it one little bit:

        S: {
            Arcmarks:            new Arcmarks()
        },
        E: {
            fm:                  '#fm'
        },
        J: {
            fm:                  '#fm'
        },
        init: function () {
            $A.machine({model: this.Name});
        },
        initJ: function () {
            var self = this;
            $A.Event.add('malleable', function () {
                self.J.fm.draggable();
                self.J.fm.draggable('enable');
            });
            $A.Event.add('malleable_not', function () {
                self.J.fm.draggable('disable');
                self.J.fm.draggable('destroy');
            });
        },


Your methods are mostly simple and nice, but unless you're writing a web app different from 99,9% web apps out there, you seem to have chosen wrong abstractions and bad naming.

**This is a rather unusual problem: your methods *seem* so simple I feel like I'm missing something, but I've re-read code several times, and I just don't get it.**

I encourage you to try to look at the code from a new team member's perspective. Do you really understand what's going on? The problem is exemplified by the fact that it depends on other modules with just as unfortunate method naming, like `someKey`.

I'm sure all great programmers go through this stage, [described by Joel](http://www.joelonsoftware.com/articles/fog0000000018.html):

>When great thinkers think about problems, they start to see patterns. They look at the problem of people sending each other word-processor files, and then they look at the problem of people sending each other spreadsheets, and they realize that there's a general pattern: sending files. That's one level of abstraction already. Then they go up one more level: people *send* files, but web browsers also *“send”* requests for web pages. And when you think about it, calling a method on an object is like sending a message to an object! It's the same thing again! Those are all *sending* operations, so our clever thinker invents a new, higher, broader abstraction called *messaging*, but now it's getting *really* vague and nobody really knows what they're talking about any more. Blah.

>When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.



Your code seems to suffer from architecture austronautry.

All great programmers have been there—the “a-ha” moment comes when you revisit such “smart” code months later and have no idea how it worked, how to fix, extend or explain it to somebody else.