So, it seems that the purpose if Behaviour classes is a bit unclear. You can’t do anything else with Low Pro that you couldn’t do another way. It *is* just a way of working and organising larger applications. It does have a number of really large advantages though:

1. It allows you to create front end components that are completely decoupled from the mark up and each other. The configuration of these comes at the binding layer (when you use $().attach()) which is a much better than the alternatives which are either custom attributes or unsemantic use of class names).

2. It gives you a easy to use inheritance mechanism so its easy to take existing behaviors and add or adapt their behaviour in any way you like. For instance, I often bulid on Remote.Link or Remote.Form to create any behaviour that deals with Ajax. This is a big advantage over standard plugins where you nearly always need to depend on hooks the plugin developer uses for you or hack the source yourself. However, Im not saying that behaviours should replace plugins. They work alongside each other. For example, something like livequery is a good example of something that should be a plugin but on the otherhand, I think that a UI component such as a calendar widget would be better suited to being a behavior as a large degree of customisation is often needed.

3. Probably the biggest advantage for me is that it guides my way of designing front end code. With behaviours I can treat each part of the UI as a distinct entity rather than having to comprehend the whole UI at once. Even really complex interfaces are easy to split up into very small discreet behaviours. Once you’ve got these behaviours you can mix and match across your project, extend them, reuse them on other projects. Your front end code becomes I collection of useful tools rather than a bunch of functions that only work on that particular page. It’s something that I only realised after using it for a while.

If you have the time to try it I think you’ll see the benefits pretty quickly. If you don’t then fair enough, it’s not buying you any new JS super powers or anything. But then again, what is jQuery apart from a new and better way of achieving the same result?

“I think in the end this is just a difference in opinion. You’re obviously a hardcore jQuery advocate, and while I certainly consider myself one too, I’m open to the possibility of using jQuery as a tool for developing larger apps in different ways.”
Best of luck. I am open to anything once I see an example of something I can’t already do in a straight forward way.

You did mention contributing back to a plugin, but in reality this is not what most developers want. Try considering this from a production environment point of view: In a production environment I want the tools available to me that I can customize on the fly!

Side note noted! That site was written by another developer here over a year ago. You’ll also note then that we no longer use mootools in any other more recent project to my knowledge, and that the JS on our main site, while separated into Objects, is not really OO and is only really split up into namespaces. So while your argument may be true for some people, it’s not for us and is anecdotal at best.

I think in the end this is just a difference in opinion. You’re obviously a hardcore jQuery advocate, and while I certainly consider myself one too, I’m open to the possibility of using jQuery as a tool for developing larger apps in different ways.

“The common use case I come across is having to use a component/plugin on the same page or site, however each use requires slightly different configuration or functionality.”
I don’t see how hacking a plugin externally with low pro, helps over modifying the plugin itself and sending the author the code updates. Ultimately the plugin author needs to integrate the code you need - it is better for everyone that way.

“And no, providing a massive options object for configuration doesn’t classify as easy in my definition.”
Plugin authors have been modularizing the code instead of providing a massive options object. I need to follow the modularization practice going forward. We are all learning here what the best way to code plugins is.

side note:
“low pro serves as an intermediary step between switching from mootools/prototype to jQuery” -me.
Your company’s website, http://www.jbinteractive.com.au/ is using MooTools. It seems anyone using lowpro is a convert to jQuery.

You might argue that you can do the same with a plugin architecture, and while this is somewhat true it’s often inconvenient and usually the responsibility is with the plugin author to make a developers life easier. And no, providing a massive options object for configuration doesn’t classify as easy in my definition.

The common use case I come across is having to use a component/plugin on the same page or site, however each use requires slightly different configuration or functionality. With your average jQuery plugin I need to open the source, fiddle around until I can abstract the bits of functionality I want to replace.

Great article btw, if you can do another demonstrating these advantages you might pursued a few more people that this is a good idea

Learning jQuery » Using Low Pro for jQuery…

Well screw that, then. Happiness and productivity are benefits for weaklings.

I’m building some complex forms with it, and with permission of my work I might use some of that code in another tutorial.

Another thing is coming from me coming from an OO background, I find LowPro’s way of handling the prototype nature of the language much easier to handle.

Thanks