Being an intermediate jQuery user, I found the book a bit too basic. It seems to be written mostly for beginners. With that being said, it is an excellent book for beginners. I was really impressed with the quality of the examples. The authors always keep in mind progressive enhancement and graceful degradation. They even mention event delegation! Those are a few topics I wish I knew about when I first started JavaScript development. They are good habits to get into.

Though you should probably have an understanding of JavaScript before learning jQuery, there is also some good material that applies to general JavaScript authoring, such as closures. I found the description of events pretty comprehensive as well.

Anyone will find useful the list of resources and plugins at the end of the book. Something missing from the jQuery plugin repository is a way to filter through bad plugins to find the good ones. The list of recommended plugins in this book is a good place to start.

If you’re a jQuery beginner, I highly recommend this book. If not, you might want to pass it up for something more advanced. Here is a sample chapter on effects if you’d like to take a look

To get the latest code, check out trunk with svn: http://valerie.googlecode.com/svn/trunk/

None of the documentation is up to date in the docs folder, but the inline documentation is. There’s also a working demo to take a look at.

I’m particularly looking for feedback on ease of use. Let me know what you think!

Related to a previous post, you can view docs generated from the inline documentation, but note that this is a work in progress and the location will definitely change once it’s ready to be released.

Enjoy!

// ** {{{ App.addMenuItem() }}} **
//
// Adds a menu item to the {{{element}}} DOM node showing the {{{label}}}
// text.  If {{{urlOrCallback}}} is an URL, choosing the item causes a new
// window to be opened with that URL.  If it's a function, it will be called
// when choosing the item.
//
// If the node does not have a menu yet, one will be created.

I think this renders the inline documentation unreadable. Natural Docs has a lot nicer format that would look like this:

/*
  Function: App.addMenu

  Adds a menu item to the element DOM node showing the label
  text.  If urlOrCallback is an URL, choosing the item causes a new
  window to be opened with that URL.  If it's a function, it will be called
  when choosing the item.

  If the node does not have a menu yet, one will be created.
*/

So I took Code Illuminated and made half of it into a PHP script so it wasn’t limited to same-domain ajax calls. I also added a very basic Natural Docs parser and a Markdown parser, code highlighting courtesy of GeSHi, and caching. Here’s a demo. It’s nothing special right now and needs a lot more work. In particular, I need a full-fledged Natural Docs parser in PHP. Anyone have one handy?

Is anyone interested in this? I’ll be using it for JibberBook documentation, but I don’t know if I’ll release it unless there’s an interest in it.

I made it more flexible than the original because now you can use whatever effect you want. There are four custom events that I’ve added, and here are the defaults:

$('#containerId').emenu({
  over: function(event, bg){
    bg.stop().fadeTo(400, 0.5);
  },
  out: function(event, bg){
    bg.stop().fadeTo(400, 1);
  },
  show: function(event, ul, li, width, height){
    ul.css('visibility', 'visible').stop(true).fadeTo(200, 1);
  },
  hide: function(event, ul, li){
    ul.stop(true).fadeTo(200, 0, function(){
      ul.css('visibility', 'hidden');
    });
  }
});

There are three ways to add your own. You can overwrite them like above by passing in your own or you can do $.fn.emenu.defaults.[event] = function(){…}. Plus since they are custom events attached to the container, you can also do $("#containerId").bind('emenu.[event]‘, function(){…}). Keep in mind this won’t overwrite the defaults unless you unbind them first.

The custom events receive a few arguments worth explaining.The events over and out receive the div element that contains non-menu-related content; show and hide receive the item menu moused over/out and its submenu. Additionally, show receives the height of the menu and the width of the submenu if you’ve used auto-calculation.

There’s a demo and additional options listed on the plugin page.

I think I’ll be working on converting my other scripts to jQuery as well so keep an eye out for them!

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?