Comments on: MooTools Behavior

By: aaron

aaron — Thu, 22 Dec 2011 21:48:26 +0000

@SJ, it's a balance question to me. We are always balancing bandwidth, performance, and development. Code patterns that make for easier development can have a big impact on building a better product at the cost of bandwidth or performance. If you optimize for performance that might mean a less interactive experience. What balance works for you and your product is something for you to decide.

That said, I think that, unless you're talking about a page with thousands of items that have this markup in them, the bandwidth change is likely to be minimal. Remember that these filters can work however you prefer. For example, a Tabs class doesn't require you to mark up each tab and each section, but rather allows you to mark up the container of the elements with selectors to find those items. In the same manner, you could author a tips filter that is only instantiated once and runs a selector to find all the tip elements (like Tips in MooTools does now). It's up to you.

By: aaron

aaron — Thu, 22 Dec 2011 21:44:34 +0000

I should note that using data properties to capture UI configuration isn’t unique. There are some things unique to Behaviorjs - the delegator stuff I think is novel but not exactly rocket science - but you’ll find similar patterns in Dojo for example. Re: Knockout JS, I’m not 100% sure what their whole story is, but the inline stuff appears to be only a small part of it.

By: Htbaa

Htbaa — Thu, 22 Dec 2011 20:08:43 +0000

Am I wrong to think this thing is similar to what Knockout JS is doing?

By: Tim

Tim — Wed, 21 Dec 2011 14:36:33 +0000

Nice stuff Aaron! Thanks for the update.

By: SJ

SJ — Wed, 21 Dec 2011 14:34:15 +0000

I'm not sure I agree with this approach. I work on website with 45000+ pages and the additional page weight and bandwidth this would introduce could be substantial. I'm guessing there would also be a lot of redundancy where the same options are repeated on different pages? And with the redundancy comes the maintenance issue, changes can't be made in a single location e.g. If I didn't want tips any more, every anchor tag in the site would need updated.

Could the same approach not be used with a single external JS configuration file?

Cheers,

By: nagaozen

nagaozen — Wed, 21 Dec 2011 11:42:25 +0000

I've been playing with Mootools Behavior and it really really seems to be, at least for me, the next big pattern in coding javascript. Although it doesn't fit very well for web applications, where you are always injecting stuff dynamically, it's BY FAR THE BEST way to work with a designers team to get a site up and running.

Congrats MooTools!

By: Anon

Anon — Wed, 21 Dec 2011 06:39:35 +0000

Yawn. Inversion of control is so 2009.

By: Jonathan

Jonathan — Wed, 21 Dec 2011 05:30:45 +0000

Wouldn't this cause HTML validation (not Mootools Validation, W3C) issues in older browsers?

Plus, I think that the net result would be more text written, meaning more bytes, meaning slower load times.

Further more, you can compress/minify a .js file, but you can't compress/minify HTML (well, sort of, but not like Javascript).