Where does MooTools come in to this? The lead developer’s official response. To me, it sounds overly defensive and rude. And when I suggested he reword a blanket statement, I got an equally rude response from another developer. Did I say something wrong?

If this were the first time it happened, I’d be ok with it, but I’ve been with MooTools since the MooFx days, and they’ve never been nice to the community. I’ve seen it expressed multiple times that MooTools is for their own (the developer’s) use and they just put it out there for other people to use if they so desire. They don’t care about the community, and I’ve found this proven by their actions time and again, and this time, I’ve had enough.

Anyone remember when the jQuery site got redesigned with the javascript rockstar? Remember how quickly it was removed based on user feedback? If you don’t like jQuery as a library, you definitely have to respect their attention to the community. Now here’s the opposite response. MooTools 1.2 was released, and with that release, the forum was removed. There was no prior warning and it was weeks before we had any official word on what happened to it. Understandably, a lot of the community was upset. If I had discovered MooTools in that state, I would not have adopted it, but even after that, I stuck with MooTools hoping they would get better at interacting with the community.

But they haven’t. I don’t know if Valerio just doesn’t have good people skills or if he’s really a jerk or both, but I think MooTools could benefit from a PR person (and I’ve told them this), but it’s too late for me.

For the record, I think MooTools should stick with it’s own selector engine, and I think MooTools is the best library for a majority of my needs, which is why I’ve waited so long to ditch it. I just can’t stand behind it anymore. Farewell, MooTools. Let me know if you ever decide to care about the community you should be fostering.

(function(events){
    var methods = {};
    for (var event in events) {
        (function(ev){
            methods[ev] = function(fn){
                return (fn) ? this.addEvent(ev, fn) : this.fireEvent(ev);
            }
        })(event);
    }
    Native.implement([Element, Window, Document], methods);
})(Element.NativeEvents);

I can also use $(el).click() to trigger the click event just like jQuery.

Next, let’s say I like $(document).ready(fn) better than window.addEvent(’domready’, fn). Just do the following:

Document.implement({
    ready: function(fn) {
        window.addEvent('domready', fn);
    }
});

And finally, while this is purely aesthetics, I like $(el).is(selector) better than $(el).match(selector). Internally MooTools uses alias() to assign the same function multiple names so I can do that too like this:

Element.alias('match', 'is');

With these changes I can now use this code with MooTools:

document.ready(function(){
    $('myLink').click(function(e){
        if (e) e.preventDefault();
        alert($(this).is('a'));
    }).click();
});

And combined with some simple wrappers for jQuery, this is also valid jQuery code.

Writing POJS (plain old JavaScript)

This is probably the most obvious, but least optimal, solution. Just write code that doesn’t use a library. The down-side is that you can’t take advantage of what’s available to you resulting in re-inventing the wheel and a larger code base. The biggest plus of using this method is portability as it isn’t dependent on anything else.

As far as examples go, there aren’t any specific ones since it’s hard to tell if the author didn’t use a library to increase portability or compatibility, but date.js is a useful library that benefits from that portability.

Detect Libraries

This second method is similar to detecting browsers and writing browser specific code, and that is detecting which library is being used and writing code specific to that library’s syntax. While you don’t necessarily have to re-invent the wheel, you have to duplicate code logic for each library. Also, when introducing dependencies you introduce more potential bugs. When a new library comes out, more code will need to be written to support that library.

I’ve found this technique being used in PURE, and you can find one of the down-sides at work. It just recently gained support for its second library (even though from the beginning it was planned to support multiple libraries).

Adapter

This last technique involves creating your own API and writing adapters or wrappers for each library and its functionality. This method sort of combines the benefits of the previous two in that you can take advantage of existing code while keeping repeated logic out of your core code.

Ext JS is a good example of this. Not only does it have adapters for YUI, jQuery, and Prototype, but it also has it’s own adapter if you’re not using a library, effectively combining the first and third methods. Ext JS enjoys maximum portability, while keeping the core code small, but this combined method requires the most work.

My Vision

I’d like to see a cross-library library of sorts. Including this library would automatically load an adapter for a previously included library that it detects or load its own core code if one is not found. This would provide a common API to build your code on and make the library used transparent to you. To take it a step further, it could also provide any functionality not provided in your library of choice.

Are you aware of any other solutions?

But hanging out at BarCamp really makes me want to start a web/tech community here in Manitowoc. I haven’t figured out the first step yet. There aren’t any groups to hook up locally (and I’d really like it to be local). I’ll probably have to hit up the colleges around here, maybe organize something with Silver Lake College (my alma mater).

Anyway, here I am introducing myself:

This marks the last feature release for JibberBook 2. Next up is JibberBook 3, a complete rewrite to make it a more flexible commenting system. Anybody want to help?

• A demo is now included in the download
• It can be used with Mootools or jQuery
• A helper class to output values for non-js
• Error display plugins (only 2 right now, but you can write your own easier)

This is especially a problem when using Mootools because the developers don’t care if their library isn’t compatible with others. I’m seriously thinking of dropping Mootools from JibberBook and using POJS (I’m coining a new term here: Plain Old JavaScript) so it can be used by more people.

I know some libraries have a no conflict mode, but there’s also the less-than-desirable side effect of forcing visitors to download multiple JS libraries.

It’s our responsibility to come up with a solution. In the far future, I think the optimal solution would be to create a standard API that all JS library developers will agree to use. That might be a while off, but for now, an intermediate step would be to create wrappers for JS libraries to implement the same API. I’ve already created some simple wrappers for jQuery and Mootools for Valerie, but I don’t believe I have the expertise to create what’s needed. Any JavaScript guru out there willing to take up the challenge?

My version includes files in a similar manner, and has text, html, and set includes. I chose to use YUI for a javascript library because it provided a lot of the functionality I needed out-of-the-box. Anyway, take a look and let me know what you think.

Here’s the code I used to get the feeds:

$feeds = getFeeds(array(
    'blog' => 'http://www.chromasynthetic.com/blog/feed/',
    'delicious' => 'http://feeds.delicious.com/v2/rss/chryu',
    'twitter' => 'http://twitter.com/statuses/user_timeline/12885402.rss'
));

Download the script.

I had a look at my Valerie code again and realized how small it really is: only 242 lines! So I have a question for the community. Would you use a framework to rebuild a simple app?

Here are the pros and cons as I see them:

Pros

• Well documented
• Well tested
• Not maintained by me
• People using Zend Framework might be more likely to use Valerie

Cons

• Larger code base
• Valerie already works fine
• Will probably slow Valerie down
• People not using Zend Framework might be less likely to use Valerie

What are your thoughts?