(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?

Ideally, I’d like a development team so if you’re interested in helping out with JibberBook, let me know, but I’d definitely appreciate patches and code improvements.

Most of the request tickets now change some of the core behavior of JibberBook and require a bit of modification; therefore, I think I’d like to rewrite JibberBook from scratch to make it a more flexible and reusable comment framework rather than just a guestbook. It would also be cool to write adapters for the major javascript frameworks instead of using just one (Mootools). It wouldn’t be JibberBook anymore, though. Probably JibberWork or something like that.

Form validation has already been isolated in Valerie which I’d like to use in the next iteration of JibberBook.

There’s also an idea that’s been on the back burner for a while now and that’s to make some sort of embeddable guestbook so users don’t need to do any installation and don’t even need a server that supports php. I haven’t figured out how to do this technically yet, though.

If you’ve got some good ideas and think you could devote some time to help out, let me know and I’ll get you added to the project! Thanks!