jQuery, MooTools, the Ajax Experience, Programming to the Pattern, and What Really Makes One Framework Different From Another

Friday, October 3rd, 2008 @ 1:21 am | filed under: Best Practices, MooTools

I just got back from the Ajax Experience in Boston and I’ve had a lot of stuff on my mind.

jQuery Has A Posse

First, I must first attest that hands down, jQuery was the most popular and well represented framework there. They ruled the roost. John Resig (creator of jQuery) spoke 7 times in 3 days, Microsoft demonstrated how jQuery is included in its SDK, and the crowd attending was definitely there to talk about the framework. More than anything, this made it clear to me that jQuery is doing something right.

Part of the task I set for myself in attending the conference was to attend as many of these jQuery sessions as I could both to learn as much of jQuery as I could (I have, in the past, dug into it, but I wanted to soak up as much as I could from the development team and John) and also to see if I could pick up on what accounts for the popularity of the framework.

This requires a bit of explanation. The MooTools team (of which I am a part) has never really focused on how popular the framework is. We are interested in writing it for our own use and for its own sake, but we don’t really spend much energy trying to convince other people to use it. We don’t consider ourselves adversaries to other frameworks – as I’ve heard it put on numerous recent occassions, we’re at war with the browsers, not each other. In my own posts on the topic, my suggestion to people is to try a couple of options and choose the framework that suits your needs and your styles. You really can’t make a bad choice (so please stop arguing about it!). jQuery, Prototype. YUI, Dojo, MooTools – we’re all doing the same things just using different methods. More on this in a little bit, because I’ve started to think about this more lately.

Bill Scott Continues to Teach Me Things

While at the event in Boston, I ran into Bill Scott. Bill worked at Yahoo on the YUI team as their lead evangelist and is a great speaker (though he wasn’t speaking in Boston other than a 5 minute “flash” talk about his current work). Bill helped to start the Rico framework a while back (I hope I don’t mischaracterize this – I don’t really know his history there), and then switched to YUI. Then he left Yahoo about a year ago and moved to Netflix and is leading the team there doing a lot of stuff – not just JavaScript (focused more on their new API and the user experience as a whole). Netflix is using jQuery and I had a chance to sit down and talk to him about that.

I want to be careful here, and remind anyone reading this that I don’t have anything bad to say about jQuery, and I don’t want to start a flame war on this post or others. jQuery and MooTools (and Prototype and Dojo and YUI, yada, yada, yada) are different and not competing with each other. They solve problems in different ways and I, personally, happen to like the way MooTools solves the problems it tries to solve. It’s way too easy for me to make an incorrect statement about jQuery as I’m still learning it, so please forgive me if I misspeak (er- mistype?) here.

Programming to the Pattern

So in talking to Bill, I spoke about some of my recent thinking about what I’ve been calling “Programming to the Pattern.” It goes something like this: when I write my code, I can choose to be an architect, or a construction worker. I can design, or I can implement. In reality, I must do both, but I can choose which one I want to do more and, in many ways, it’s possible for me to do almost entirely one or the other – though not 100%.

What the hell am I talking about? Let me put it to you this way: if you write 20 lines of code to describe a user interaction on a page to make it snazzy or easier to use, is it worth writing another 5 or 10 lines to make that code reusable? If you program the experience directly, you’ll always write it again and again. But if you program the pattern, you’ll write less and less.

Consider a user experience where, say, one has a log-in box that shows up when the user clicks “log in.” The user clicks “log in” and the box appears. The user fills out the form and the box displays a spinning indicator while it sends an ajax request. When the response comes back it tells (in the box) the user that they are now logged in and then a moment later it winks out.

I could express this as javascript right on the page or maybe in my site-wide code (presumably the log-in box is on every page, right?). It would look something like this (I’m going to abbreviate this somewhat) – note I’m using MooTools syntax here, but it looks about the same as it would in most frameworks these days, as we all borrow good ideas from each other:

[javascript]window.addEvent(‘domready’, function(){
$(‘loginLink’).addEvent(‘click’, function(e){
e.stop(); //don’t follow the link
$(‘loginPopup’).show();
});
//loginPopup contains loginForm
$(‘loginForm’).addEvent(‘submit’, function(e){
e.stop(); //don’t submit the form
$(‘loginForm’).send({
onComplete: function(result) {
$(‘loginPopup’).set(‘html’, result); //show the result
(function(){
$(‘loginPopup’).hide();
}.delay(1000)); //wait a sec, then hide the popup
}
})
});
});[/javascript]

Pretty straight forward, right? But what if we take a step back and ask ourselves, what’s this pattern here? Could we ever see a part of it again? Certainly, a popup that contains a form that submits, updates itself and then does something could crop up again. Right?

This is what I mean by “Programming the Pattern”. In my old code, I would have maybe written the code above. If it were part of my site, I might have a namespace and named this a method called “showLogin”, then called mySite.showLogin on domready. Or, maybe even more likely, my site would end up with a bunch of methods like this. showLogin, logOut, makeToolTips, autoScroll, setupDraggers, etc. Then I’d have a method called mySite.init that called all these.

But even moving back to my older code I would have just had a giant domready method with all these layout/interaction instructions all in one big startup method.

If you’ve ever had code like this, you’ll know that it’s never, ever fun to maintain. It takes a lot of effort to just understand what you were going after in the first place. Go look at that code example again and imagine encountering something like it that’s 3 or 5 or 10 times longer and imagine encountering it again a year later. Just unraveling the intended behavior can be daunting.

Now, let’s program the pattern. A popup, with a form, that updates itself. That’s a pattern that could totally crop up again. Here’s the same thing as a MooTools class:

[javascript]var PopupForm = new Class({
Implements: [Events, Options],
options: {
requestOptions: {/*the user can fill in additional ajax options*/},
onComplete: $empty //do nothing on complete by default
},
initialize: function(link, form, popup, options) {
this.form = $(form);
this.link = $(link);
this.popup = $(popup);
this.setOptions(options);
this.makeRequest();
this.attach();
},
makeRequest: function(){
this.request = this.form.retrieve(‘send’, this.options.requestOptions);
this.request.addEvent(‘complete’, function(response){
popup.set(‘html’, response);
this.fireEvent(‘complete’);
}.bind(this));
},
attach: function(){
this.link.addEvent(‘click’, this.show.bind(this));
this.form.addEvent(‘submit’, function(e){
e.stop();
this.request.send();
}.bind(this));
},
show: function(){
this.popup.show();
},
hide: function() {
this.popup.hide();
}
});[/javascript]

Now, my class is admittedly nearly twice as long, and it still isn’t attached to my login link. To make that work, I have to initialize it:

[javascript]window.addEvent(‘domready’, function(){
new PopupForm($(‘loginLink’), $(‘loginForm’), $(‘loginPopup’), {
onComplete: function(){
(function(){
this.hide();
}.delay(1000, this)); //wait a sec, then hide the popup
}
})
});[/javascript]

Trade-offs, But Big Benefits

So in addition to being twice as long, I had to bang out another 9 lines before I was finished. 15 lines vs 42 doesn’t look like a good trade off, but lately this is how I write nearly all my code. Changing to this way of thinking has saved me from writing many, many more lines of code and saved me a lot of time in ways I hadn’t originally considered.

  • My code is now far more legible. I have small methods that just do one thing and I know what it’s doing and why. My classes are named things that describe what they do, and the classes themselves are small things that just do one thing. If I need a class that does two things, I write two classes and a small controller class that calls them.
  • My code is reusable – if the pattern ever comes up again, I don’t have to write it again. I’ve amazed myself in how often this has happened. Stuff I never, ever thought I’d reuse ends up coming back to me in a week and there I am using it again.
  • The points where my application – the web page I’m working on at the moment – touches my generic code are very small. I don’t write much code about the pages themselves – all I do is instantiate classes for a given page element. This small footprint means that there’s less code that’s only good for that page.
  • When it’s time to refactor – perhaps there’s a new version of the framework I’m using, or a new browser bug is found, or a new browser hits the market (oh, hi chrome), or I find a bug in my own code (which is the most frequent of all these reasons), I have to go fix it. If I’m writing all my code for each page I have to go refactor it everywhere. If, on the other hand, my pages just instantiate my classes, I only have to refactor my classes. Since I control the interface to my classes, I can completely rewrite the class without having to touch the code that instantiates them.
  • Finally, I end up changing the way I think about the user experience I develop. I’m much more likely to develop an experience and reuse it than create a new one from scratch. This creates an experience consistency that, to me, means a better user experience.

Extensibility – Because I Like To Tweak Things

This brings me to the last big benefit that coding this way provides, assuming that you are writing your code in a way that lets you take advantage of it: extensibility. MooTools has a class based hierarchy (inspired by Dean Edwards excellent work), but don’t let the name fool you. It’s called a class but it’s really just an object factory that makes taking advantage of the prototypal inheritance model in JavaScript easier.

You don’t need MooTools to do this of course. JavaScript will let you do it yourself. But because this is the way MooTools works from the ground up, it makes it hard to avoid writing your own code this way. Writing your own classes is really easy, and extending a class – even if you didn’t write it – is easy, too.

Let’s take our FormPopup above. let’s say we want to have the popup appear with an effect. Just to make it interesting, lets say that there is already code out there using it, so we don’t want to alter it, but for the page we’re on, we want the popup to fade in and fade out rather than just appear.

MooTools lets you take any class (even the ones you didn’t write) and extend them into new classes. You don’t need to duplicate the whole class to add your differences – you only write the part you want to add or change.

[javascript]var PopupForm.Fx = new Class({
Extends: PopupForm,
show: function(){
this.popup.setStyles({
opacity: 0,
display: ‘none’
}).tween(‘opacity’, 1);
},
hide: function(){
this.popup.tween(‘opacity’, 0).chain(function(){
this.popup.hide();
}.bind(this));
}
});[/javascript]

Now we have a new class called PopupForm.Fx that will fade the popup in and out. We haven’t changed PopupForm at all. What’s more, if we later find a bug in one of PopupForm‘s methods, we can fix it in that one place and it’s fixed for both classes AND all the places we use it.

When I write my code this way, it means that every page, site, and project I work on I add a few more tools to my toolbox when I go to the next project. I’ve released over 70 plugins for MooTools in the last year or two, and this is just the code that I thought other people could use. Form validators, date pickers, and more. I’ve written many more extensions for my own projects that aren’t so generic, but they are no less reusable for my own work.

Looking Under the Hood

All this brings me back to what I really wanted to talk about, which is my thinking about MooTools and what makes it different from many other frameworks. Watching the jQuery presentations (again, jQuery is just different – not better or worse), I realized that MooTools and jQuery are very different in the solutions they present.

When talking with Bill Scott about his team and their use of jQuery, I asked him about what they do to program to patterns. Bill’s a great guy to ask about this because he spent a lot of last year giving a great talk about user experience patterns and YUI (I highly recommend it). He lead the project for the whole YUI pattern library. Here’s a guy who is all about creating patterns for reusability. I asked him about working with jQuery, which has mechanisms for creating plugins, but not a way to extend those plugins and, frankly, the plugin mechanism seems a little awkward to me (for instance, if you want to call a plugin method, you must do jQuery(domId).pluginName(“methodName”, [arg1, arg2]); – I hope I have that right – this seems incredibly esoteric to me).

After hearing me talk about the reusability and extensibility patterns built into MooTools, he made an excellent point: He knows enough about JavaScript to have his own methods for making use of JavaScript’s inheritance mechanisms. In other words, he uses jQuery for DOM manipulation and effects and for some of its plugins, but when he writes his own code, he has his own class system (I don’t think he used the word “class” though – but basically some sort of factory to create reusable and extendable objects).

JavaScript Has Its Own Methods For Reuse

This, frankly, was something I hadn’t considered. jQuery is really, really good at obscuring the DOM and its headaches from the user. It’s simple to use and very expressive. Viewed as a part of a broader framework (i.e one in which the user is just making use of JavaScript’s inherent potential as an object oriented language) it makes a lot of sense.

But then Bill said something else that made me seriously consider the participants in all the talks at the Ajax Experience. He said something to the effect: “But I guess I just never really thought that other people wouldn’t do that.” That other people would use jQuery (or any other Framework, or even just vanilla JavaScript) and NOT make use of JavaScript’s (somewhat hidden) inheritance system.

This is when three things clicked for me. Three really big things that, to me, only reinforce my preference for MooTools.

Everyone Is a Noob At Something

The first big thing was that a lot of people (maybe not all, or a majority, or even a third – who knows) using the frameworks don’t think think this way. MooTools users, jQuery users, YUI users. They just write the code to get the page to do what they want (and to be clear, I wrote a lot of my code this way until earlier this year – now almost everything I write are classes). These people are excited about what they are able to do in the browser and they are excited with how fun/powerful/slick/usable/whatever their sites are. When they need to refactor them, it will be painful, but they are happy non-the-less (again, I am/was one of these people – I’m not talking down).

I think it’s safe to say that of all the frameworks, jQuery makes this experience easy to get into. It so completely obscures the browser and feels so much like CSS in many ways that it’s like a gateway drug. You do a little, and then you can’t stop. If jQuery has accomplished nothing else, it has introduced a lot of people to JavaScript and got them to stick around. This is no minor accomplishment.

But We All Learn Eventually

The second big thing that became apparent to me was that sooner or later, people writing this way are going to get really, really good at it, and when they do, they’ll want to be more efficient. They may not take the same road as I’m currently on – the number of frameworks out there illustrate that there are a lot of ways to skin this cat. But they will get past the “hey look, I can make a slick ajax login box” phase and will want to start developing code that’s easier to reuse, maintain, and extend. That’s when they’ll re-read Crockford’s book and ask themselves why they aren’t doing some of the stuff in there.

Again, regardless of which framework they are using, this is going to happen. Step one: learn javascript syntax basics. Step two: learn to do some fun effects/ajax with a framework. Step four through seven hundred and nineteen: make a bunch of stupid mistakes and learn some stuff the hard way. Step seven hundred and twenty: get really good at JavaScript and look back on your previous work with disdain. This is the way of all programming experience, am I right people? (Hey, afford me one generalizing, sweeping statement about all programming languages, ok?)

With Frameworks, What Matters Is Hidden Deep Inside

And this, finally, led me to the third big thing. The thing that reaffirms my choice of MooTools. All the frameworks out there are increasingly becoming very similar to each other at the edges. I.E. they all eventually look something like this:

[javascript] fetch(element).verb(details).verb(details).verb(details)[/javascript]

The only real difference is terminology. One framework might use $, another might do something like, oh, Y.get, or jQuery(id), followed by different verbs that are synonymous with the next framework. At the edges, they all do the same thing. This is because we all see good patterns in each others’ work and incorporate it – again, we’re all working against the same thing – the browsers – for the same purpose.

But where they are different is deep down in the core. The developers of these frameworks don’t spend their days writing code to animate login boxes. Sure, they write that stuff for their own projects, but the framework work itself is down inside. Sooner or later, anyone starting out learning one of these frameworks is going to get to a point where writing code at the edges are going to want to start making use of the mojo down in the core. They are going to re-read Crockford’s book and think, “I am going about this the hard way – I’m repeating myself too much, and that thing I wrote today was almost, but not quite, identical to the thing I wrote yesterday. There has to be a better way.” People like Bill Scott are already doing this, but everyone just getting started are still impressed by seeing something bounce on the screen (as well they should be).

When they get really good and are ready to take that next step, they will look to the core of their library of choice for guidance. After spending months grinding out code with whatever framework they started with, they’ll look to the experts of that framework for answers, and the experts are writing the core. Every framework has a mechanism for writing plugins and extending them and I will admit that I am only familiar with a few of them in a cursory manner. I cannot pass judgement on any of them save MooTools, so I’ll limit my pronouncements to that. Nearly all of the functionality in MooTools is implemented as extensions to native objects (arrays, strings, etc) and classes. Throughout the library the principals of (shallow) inheritance and reuse are illustrated in an easy to read and easy to use manner. It is because of this that my own code has gotten so much better than it used to be (and I’m a contributor! – don’t hold that against the framework, please).

Why MooTools Rocks (At Least, Why I Think It Does)

So now, when people ask me why I think MooTools is the better choice, I’ll still tell them that it’s not about what’s better than the next one, and that all the frameworks are good choices, but the reason that I, personally, prefer MooTools is finally something I can put into words. All the frameworks achieve similar goals in different ways, but, for me at least, MooTools helps me solve my design and implementation challenges once, which is definitely good enough reason for me.

Update

There were a few inaccuracies (or perhaps vagaries?) in this post that merited a followup.

32 Responses to “jQuery, MooTools, the Ajax Experience, Programming to the Pattern, and What Really Makes One Framework Different From Another”

  1. Ajaxian » Thinking about the difference between frameworks Says:

    [...] wrote a really nice post on some of these thoughts that goes into detail on different patterns for JavaScript programing. The meme at the show was [...]

  2. krukow Says:

    Good post. I agree with your observation. However, I do not agree that all frameworks are the same in the manner described.

    The ExtJS framework has much focus and support on reuse and abstraction. As far as I can see this lifts one higher than a framework like jQuery. I could be wrong though, as I am certainly no jQuery expert :-)

  3. ahfeel Says:

    What you said is exactly how i felt at the Ajax Experience too. I booked the first day to attend every jQuery talks to discover it after using Mootools for +2 years now and i went to ask Paul Karaus (jQuery UI creator) how does he deals with code reusability between drag’n drop and sortable given jQuery plugin style, and his answer was “actually, that’s the caveat…”. Then i asked him how, as an everyday developper, he deals with everything jQuery doesn’t provide, all the Javascript sugar, and his answer was “That’s a good question… I usually code my own”. I felt really weird hearing that from a library creator. He told me he had a project of creating something bigger, including jQuery + UI + Sugar, but it’s just an idea right now. So yeah, i feel just like you, jQuery does some fucking pretty things, his selector engine is awesome and the chain pattern is very cool for doing little UI things, but it’s just not the tools to use to build javascript applications.

    This lead into what we all says: Framework are just fucking good at doing what they’re meant to, and that’s it.

    Anyway, thanks again for your sympathy @ TEA,
    Jérémie BORDIER, the french guy =)

  4. Cloudream Says:

    The PopupForm class looks like jQuery UI’s code, so it’s nothing about libs, but how you code. :)

    Mootools has really nice animation effect, but jQuery focus on ease and file size.

  5. TheUiGuy Says:

    Look, Ajaxian digs jQuery. John resig is an evangelist. When you have that kind of combination, its no wonder that we have wide-spread support for jQuery.

    I use jQuery and mootools for different projects. I code in both styles. I can tell you that it all just matters as John Resig says clearly: “how do you want to write javascript?”

    If you are like me and want the flexibility of object oriented “classes” then prototype or mootools is for you.

    If you are like me and want a very easy (and very terse) way to write css-oriented coding patterns with the snap of your fingers, then jQuery is for you.

    if you are like me and like to write in both major styles (namespace oriented versus object extension oriented) then any toolkit is for you.

    But not everybody has 10 years of development experience in the front end. If the concept of javascript scares you a little, then by all means I urge you to become a part of the burgeoning jQuery community. I am.

    If the concept of javascript does not scare you, and you think in a classical oop way, then I urge you to help mooTools create their woefully inadequate support system through your plugins and tutorials, much like Aaron Newton has done at clientside.

  6. Charles_Phillips Says:

    jQuery gets a unfair bad rep for extensibility — the sheer popularity of jQuery mean that a large number of users aren’t using jQuery to its full potential.

    Aaron, I develop with jQuery the same way you develop with MooTools — when I see a pattern emerging, I create a plugin and extend jQuery. It’s simple to create your above example — just use jQuery.extend!

    http://docs.jquery.com/Utilities/jQuery.extend
    http://docs.jquery.com/Plugins/Authoring#Using_jQuery.extend_to_extend_jQuery_itself

    Also, if you want full class behavior, with super/subclasses etc., Resig has thought of this as well:
    http://ejohn.org/blog/simple-javascript-inheritance/

    Also, it’s been done for production. Here’s a good read, a recent post about this exact topic:
    http://youngisrael-stl.org/wordpress/2008/08/13/extending-jquery-ui-widgets-revisited/

    Most of all, check out Dan Webb’s port of LowPro to jQuery – http://www.danwebb.net/

    The class issue has been discussed at length — and solved — in the Groups and other various forums. Therefore, I fail to see ‘what really makes one framework different from another’… except that jQuery is much less verbose! Your MooTools code is nearly identical to jQuery — except the ‘addEvents’ drive me nuts, thank goodness for .click() and other jQ event methods.

  7. rekna Says:

    I’ve been experimenting with several javascript libraries as well… the problem is finding the right mix of features… Ext.js is very extensive, but very large and complex: steep learning curve.
    jQuery is very easy to learn, has some great features, but soon you start looking in the plugins database for much needed functionality that’s missing in the official library. The plugin feature is great, but there’s a downside as well… soon you get drowned by the number of available plugins, spending a lot time checking out which ones match the quality of the core library. It’s a good thing some plugins get listed on the main site, but still, it takes a great deal of effort to find that right mix. I’ve been working with Microsoft Ajax library as well, but don’t like their control extension framework (which is quite complex).

    But if you’re seriously writing web applications, I don’t think you can do it without digging into javascript.

  8. Aaron N. Says:

    TheUiGuy, I’m not sure I understand what you mean here: “I urge you to help mooTools create their woefully inadequate support system…”

  9. Aaron N. Says:

    Thanks for the links Charles, I have some reading to do. I think I made this pretty clear in my post, but I’m still reading a lot about and learning a lot about jQuery. I did ask questions about these topics in the jQuery talks in Boston and, for instance, was told by a member of your team that plugins weren’t extensible. I don’t mean to misrepresent your framework, so having others post and set me straight is very valuable to me.

    I also made the point (well, Bill made the point) that jQuery can be a “part of this complete breakfast” – it doesn’t ship with a class style inheritance model, but it frankly didn’t occur to me that jQuery developers out there might be making use of this pattern anyway. Viewing jQuery as the part of one’s work that handles the DOM makes a lot more sense to me (not saying that’s jQuery’s intention, but that this way of thinking of it makes sense to *me*).

    I think my main point still stands though. *I* like MooTools because it works this way from the ground up. jQuery isn’t trying to (which is fine!). Because I prefer to code this way, MooTools is a good fit for me. You can make jQuery work this way for you, too, but it isn’t really that way itself (and again, this isn’t a flaw).

  10. TheUiGuy Says:

    Aaron.. no problem. I’m really just tring to push it out there that when theey shut down doc support for 1.11 it really ticked me off. Some of us really do use it in-house and suddenly the docs went away. That to me is a bad signal, even if they want us to use 1.2. We do wire these products into money-making enterprise suites, and when support goes away, it hurts.

    Not to mention that until you did a session at the conference, I didn’t even know you had done all that plugin work. Then, I started to try to contribute, but then the in-house forums got moved. I was 99% through a post until I saw a tiny little line that said “everything is read only”. Okay, its my bad. I wasn’t paying attention.

    But, overall, I’m concerned about the longevity of mooTools. Could it be that many of the developers are overseas and there isn’t a good reach out here? Maybe. But I want to feel like I can trust this product to be there 9 months from now. And right now I don’t because I’m looking at jQuery with a little bit of envy, thinking… why not ship mooTools with the next Web Developer Studio? Or why not ship mooTools with nokia phones?

    What kind of guarantee do i have that I can look a year from now or more and know that mootools support will be there?

    I love it, don’t get me wrong, and I work with it everyday. But when I say woefully inadqeuate, I guess I am comparing it (unfairly?) To the community jQuery has, and the responsiveness of John Resig, who has an incredible “leadership” sort of role.

  11. TheUiGuy Says:

    My typing is whats woefully inadequate. ech.

  12. Aaron N. Says:

    The 1.11 docs are online: http://docs111.mootools.net/

    They’ve been there the whole time. In the blog post about 1.2 coming out, there’s even a section about all the 1.11 demos and docs: http://mootools.net/blog/2008/06/12/mootools-12-its-official/

    I’ll say again that the MooTools development team just doesn’t consider it a priority to make the framework popular. I see benefits in having others use it, but that’s me. Corporate validation of the framework isn’t something we aspire for either.

    The community issues are real though. I personally (speaking for myself) think that they arise from a disconnect between what some users expect from the framework and what the dev team is interested in providing. The team doesn’t aim to make MooTools easier to learn than it currently is. By that I mean, we don’t want to make it simpler – not that we don’t want to have more documentation, tutorials, demos etc. MooTools is focused on writing good JavaScript, and some users aren’t looking for that. They don’t want to learn JavaScript. They just want the accordion. The team doesn’t tend to cater to these people, and they often get upset that no one is focused on meeting their desires, which isn’t very practical.

    As for the longevity of the framework, it’s hard to say if any of this stuff will be around in a year. But MooTools has been around for two years now and I don’t see it stalling out any time soon. The fact that it’s not in Microsoft’s SDK or on Nokia’s phones is not, to me, a negative.

    Again, thanks for the thoughtful comments.

  13. TheUiGuy Says:

    Thanks for the response and the links!

  14. On javascript frameworks: unbiased throughts by two of the legends… | frag (fr?g) Says:

    [...] guess I can now busk in his spotlight. So… A great and post cleverly and succinctly entitled jQuery, MooTools, the Ajax Experience, Programming to the Pattern, and What Really Makes One Framewo… comes in the same breath as John Resig’s presentation on Javascript [...]

  15. chucktrukk Says:

    I dont care either which way people go. I use jquery and enjoy others plugins.

    I wanted to use moo when I started looking into simple js. But I was scared to speak in the forums. I think I did once and got a ‘google it you noob!” reply. And the moo team has every right for that! It’s their system, their time- no qualms from me.

    But I left the moo forum to never return again. I was learning and didnt feel welcome. The jquery community feels more like “let’s learn together”. I think that’s why it’s so widespread while I see more hardcore js folks using moo.

    Again, I could care less what others use- whatever works (as long as it’s secure and working). And I don’t see the difference between your updated class and a jquery plugin full of methods and options. I guess the main difference is subclassing (a really cool thing), but I’d think you could add an animate option with a default to your core plugin (and I do see how this could get really large if you keep it up- so I sorta see your point).

    I read your stuff when I first started looking at moo and it was awesome. And keep up the work- cause we are fighting the browsers!

    chuck

  16. albinoni Says:

    The Gapjumper framework provides an interesting approach to component development; (very) loosely based on Extensible Binding Language (XBL).

    See http://www.gapjumper.com for further details and demos.

    In this framework, a generic component has the following structure:
    window["gapjumper.com"].control["NSprefix:myComponent"] = {
    "extends": [
    /*a comma separated list of components from which this component inherits functionality*/
    ],
    "initializer":function(attributes){
    /* initialization logic: logic to be carried out following initialization of children, but before initialization of its parent */
    },
    "finalizer":function {
    /* logic to be carried out following initialization of parent */
    },
    "template": [
    /* The HTML that defines the visualization of the component on the page (can also include other components). Uses a JSON syntax. */
    ],
    "properties": {
    /* properties, and optional default value, setter and getter */
    },
    "methods": {
    /* component methods */
    },
    "handlers": {
    /* handlers for any events to which the component should react. Includes standard browser events (load, resize, click etc) as well as useful custom events such as mouseenter and mouseleave */
    },
    "destructor": function() {
    /* any logic to be carried out when the component is destroyed programmatically */
    }
    }

  17. Aaron N. Says:

    @chucktrukk

    The MooTools forums have been historically somewhat unruly. The dev group doesn’t treat people this way of course, and there are always going to be some people in a community that aren’t that nice to have around. In our own writing, we definitely encourage people to behave and be civil. My own mantra is “If you can’t say anything nice, help someone else.”

    If there’s one thing I could magically snap my fingers and change about MooTools it would be the impression that we aren’t interested in helping people. We ARE interested in helping people, but we aren’t interested in helping people who don’t want to learn. If someone shows up and asks (for the 1000th time) how to get Accordion to work, it’s clear that they aren’t trying very hard – there’s documentation, downloadable demos, and the tutorials.

    But when people show up who are trying to learn we’re very responsive. Maybe this is a big difference between other communities and ours. I will say that the dev team makes a point of never being rude or mean to anyone. We might tell them that the question they are asking has been answered on the forums before (perhaps many times) and that they should please search first, or we might tell them to look at the tutorials and documentation, but we’re never rude or demeaning.

    Still, it’s good feedback for us to hear – part of our job is to ensure that people have what they need to learn the framework.

  18. RIA Revolution » jQuery, MooTools & the Ajax Experience Says:

    [...] Newton of MooTools writes an interesting blog post titled: jQuery, MooTools, the Ajax Experience, Programming to the Pattern, and What Really Makes One Framewo…, where he compares the different JavaScript (Ajax) frameworks, explains writing code that complies [...]

  19. samgoody Says:
    1. Mootools does not have any well organized or responsive forum.
      It does not even have all of the many useful threads that were written for 1.1 available.
    2. What it does have – a Google group – is so undermonitered that John Resig’s profile shows up on the home page (now what does that say about JQuery responsiveness)!
      I have never, never! gotten a response to any of the requests I have made on the Google group page, despite my not being a noob.
    3. No plugins are available unless you already know where to find them, or you write them yourselves. As oppossed to J which makes it easy to get plugins.
      Yes I know they posted something on the blog.
    4. SVN was dumped for GIT. Maybe not bad from a technical standpoint, but I don’t know how to use GIT, and am not about to start.
    5. I rarely see you on IRC, probably because we have different hours. But it is very difficult to get answers there, and thread is downright insulting to noobs – no matter how much he wants to learn.
      Worse though, the channel is not be stored. All of the questions and answers that are served are only to individuals – they cannot be accessed by someone who is searching for an answer.
      And lets face it – IRC is not good for most users. Is it so hard to have a chat box on the screen that allows for normal people to communicate, or at least to be able to see the thread?! I know a good framework that can be used to write such a tool!
    6. The site had big downtime problems, don’t know if they were resolved.

    In other words, Mootools gives a strong impression – we wrote this for ourselves, and not for you, you lowlife worthless noob. We don’t want a community, and we are not looking to grow. If you want a lively community, or want to contribute, or just want to feel proud to be a part… JQ is down the block.
    You want to use our project, we’ll let you, just so long as you don’t bother us too much.

    Don’t get me wrong, I’ve been using Moo (& clientside classes) for years, and love the framework. I tried JQuery when I got fed up with the attitude here, but had to come back as JQ just wasn’t for me.
    But why are we doing this to ourselves? Do the others mods really have such an attitude? (I know you do not, from our conversations.) What happened to the attempt to make an http://our.mootools.net? Why cant you add a link to the old forums? Why are you on Google? Add a note in the blog that you actually care about your users – people believe it when you say it, and it will make a big difference to alot of us!

    Why is it that to post this comment to mod in a way I thought it might be read, the only way I could do it was on clientside?!

  20. Aaron N. Says:
    • Mootools does not have any well organized or responsive forum.
      It does not even have all of the many useful threads that were written for 1.1 available.
    • What it does have – a Google group – is so undermonitered that John Resig’s profile shows up on the home page (now what does that say about JQuery responsiveness)!
      I have never, never! gotten a response to any of the requests I have made on the Google group page, despite my not being a noob.

    The MooTools forums used to live at forum.mootools.net but maintaining them was problematic for numerous reasons. The hosted forums were shut down and moved to Google Groups (http://groups.google.com/group/mootools-users) and the community has opened up and maintains it’s own traditional forums (http://mooforum.net/). I’ll point out that MooTools was the first framework to offer a forum at all, and the fact that we moved it to another provider is not a lack of a forum. As far as how well organized it it is or how responsive it is, that, to me, is not an indication of how well written or supported the framework is.

    Just glancing at the Google Group quickly, 1) I don’t see John on the home page and I’m not even sure what method Google uses to determine who gets shown there and 2) Looking a the list of topics here (http://groups.google.com/group/mootools-users/topics) I see 1200+ posts and in the first 100 I paged through not one was lacking a reply.

    • No plugins are available unless you already know where to find them, or you write them yourselves. As oppossed to J which makes it easy to get plugins.
      Yes I know they posted something on the blog.

    As we’ve stated, one of our current projects is a plugin repository. We also posted a request for all plugins so that we can organize them and list them on a simple page until we get the plugin repo ready. Expect this listing to appear this week.

    • SVN was dumped for GIT. Maybe not bad from a technical standpoint, but I don’t know how to use GIT, and am not about to start.

    I fail to see how this has anything to do with how users acquire our framework. How the developers of the framework choose to maintain the work has nothing to do with how well it is supported. We supply individual “built” downloads and a builder where you can roll your own.

    • I rarely see you on IRC, probably because we have different hours. But it is very difficult to get answers there, and thread is downright insulting to noobs – no matter how much he wants to learn.
      Worse though, the channel is not be stored. All of the questions and answers that are served are only to individuals – they cannot be accessed by someone who is searching for an answer.
      And lets face it – IRC is not good for most users. Is it so hard to have a chat box on the screen that allows for normal people to communicate, or at least to be able to see the thread?! I know a good framework that can be used to write such a tool!

    IRC is for users to discuss their work and seek instant help. The Google Group is far more suited for longer support threads. If IRC isn’t your thing, use the Groups!

    • The site had big downtime problems, don’t know if they were resolved.

    To my knowledge, Mootools.net has never suffered significant downtime (none at all, as far as I know). The forums were causing us issues (which I discussed previously), but the site itself has never been down (again, not that I’m aware of).


    But all this, to me, isn’t germane to the post I wrote above. My post wasn’t criticizing jQuery but rather talking about a style of coding. jQuery doesn’t attempt to support or inhibit this style that I’m talking about, so it’s not part of the equation. jQuery as part of a more robust methodology of writing JavaScript (utilizing JavaScript’s own inheritance system) is a fine solution. I, personally, like that MooTools makes use of this methodology, but I’m admitting that one of the things I hadn’t considered was that jQuery can absolutely be part of such a system (as Bill Scott enlightened me of).

    I’m not saying MooTools is better than jQuery, though obviously it is my preference. If jQuery is yours, that’s totally fine! I don’t see any point in writing at length about which framework is better than the other. They’re just different is all. Choose the one that works for you.

  21. Aaron N. Says:

    Nice. This craptastic individual basically stole my blog post wholesale. Well, you know. Internets. Plagarism is cool now, I suppose.

  22. evanl Says:

    Great post Aaron.

    Your blog post http://clientside.cnet.com/best-practices/thoughts-on-coding-and-new-classes-as-a-result/ pretty much describes the same situation I have been going through.

    I have recently come to the same realization as you about how I leverage MooTools classes. The more I use MooTools on my projects the closer I get to the pattern and re usability concepts you are trying to define here.

    Breaking functionality out and leveraging classes like this really does make managing more complex pages simpler.

  23. TheUiGuy Says:

    Yeah that happens all the time. One good way to look at it is that every time someone verbatim steals your stuff, at least you know its quality writing and not mucked with! how bad would it be that someone cribbed your work but then modified it.. uck!

    Good to get the word out there. Or, when is a virus a good virus?

  24. electronbender Says:

    Wow, get a cross and let’s crosify the guy!
    To try to answer samgoody, yes there was a fiasco with the forums, and there is no clear plugin repository, but if you follow the forums, you will find the plugins.
    As far as support, forums are voluntary, not payed support, and depend on individuals sharing their time for the community.
    You might want to spend a bit of time on them answering some questions instead of trying to badmouth the framework.
    As for a guarantee, do you have a guarantee from jQuery that it will be there in x years? Sure, it’s got more momentum, so that must be the guarantee that it will be here.
    So if you like mootools, help out, if not, start using jQuery, and leave the guy some air.

  25. chucktrukk Says:

    Hey Aaron,

    Thanks for the response. I’ve been watching modx grow with their community and know how hard it is to grow the support structure with wiki’s, forums and nice moderators. You’re work on the cnet tutorials is great.

    Just wanted to say thanks for your work on the OS front battling the browsers and your response.

    Chuck

  26. samgoody Says:

    Mootools is the only library I regularly use, and for which I have written many classes. Am nonetheless responding to the rebuttal.

    1. Mootools may have been the first to set up forums, but…
    I don’t know when the link to mooforums was added, but I missed it, and no doubt so did others. Why is it unofficial? How does it work with the Google group?
    We would like a nice clean clear community, and you can help that by making one forum, making it more obvious and making it approved.

    @electronbender – I was a regular poster on the old forums, and was a bit put off when I saw those posts disappear. Now I know of the new forum.

    2. I still don’t see the plugin repository, short of the unofficial forum. It’s not bad. We look forward to something a little more encouraging, at least like mooscripts.com’s.
    Even better, to encourage a community, try to promote and show off those that have written classes. Giving a way for the small time hacker to feel appreciated will generate a much more powerful “my site” feeling, that the devs and more will show off and work for.

    3. I found a bug in the swf class and made a short, clear page to demonstrate. Two posts on google groups went unanswered, as did my requests to Val (Kamicane) on IRC. I wasn’t willing to learn GIT, and assume the bug still exists. I don’t believe that I am alone.
    Please consider that we the community want to contribute to make Mootools better. Anything that would make it easier is appreciated.

    Also, while IRC is for quick answers, many of the questions are asked more than once. It would be very very helpful if the threads could be saved in some form.
    I personally hang out on IRC, but recognize that most users don’t.

    4. This is the crux, and the response to your article: The real difference between Mootools and JQuery, for many (most) users, is whether or not there is an active community in which they can feel appreciated.
    Unfortunately, Mootools can give its users a feeling of being discounted. Even if not true, being the psychological creatures we are, this makes a big difference. Please don’t defensively answer the points. Consider if they might create the image they do, and consider the suggestions above on how to address it.
    As said before, you’re the one man there I feel could actually bring back Moo, instead of shooting such a technically superior masterpeice in the foot.

  27. samgoody Says:

    chucktrukk refered to something that got overlooked:

    Modx uses Moo for its JS, as do a number of other libraries (I am working on one, Joomla || Mambo, more). I’ve yet to see any using JQuery.
    My feeling is that Mootools’ class structure is much more similar to PHP’s than is JQ’s.

    No doubt I will be yelled down for this comment :)

  28. Aaron N. Says:

    @samgoody, it’s funny. When I was talking with Bill Scott he said that “jQuery was kind of the PHP of JavaScript” – meaning that it’s perhaps the easiest library to approach.

    Regarding your other points, I’ll respond to them here, but I don’t mean them to be defensive. I’ll try and make them factual as much as I can.

    RE: 1) The unofficial forums are just that – forums that the MooTools development community has nothing to do with. We didn’t create them and we do not administrate them. To a great extent, the same is true of the Google groups – we don’t really administrate those either. The purpose here was to separate any potential bad behavior by the community from the intent of the framework developers. Like any web community, ours has a few excitable people who might say things that we, the developers of the framework, would never condone. Our intent was to separate (and liberate) the community’s voice so that it could be whatever it wanted to be. Some of the posts on the MooTools forums in the past have given the MooTools framework itself a bad rap as hating other frameworks or not being friendly to new users, which is not our intent.

    RE 2) The plugin repository is coming along, albeit slowly. Keep in mind that this particular project is secondary to our work on the framework and that all of this is done in our “spare” time. However, look for a post here later today on plugins that might be of use or interest to you.

    RE 3) Git is a pain. It is a complete and total pain. I personally loath it mostly because I haven’t gotten the hang of it. It is, however, a superior tool for managing an open source project. I can’t speak for your efforts to reach Valerio or anyone else, but I can say that we (the framework developers) try and keep an eye on the forums and IRC to be responsive. We certainly like it when people help us fix bugs! My suggestion is that you use the lighthouse system, which is where bugs belong. Post your bug and your solution there and it’s much more likely to get the response it deserves.

    RE 4) I agree with you that engaging a community is crucial for wide adoption of a technology framework that is open source. You may consider it unfortunate or not, but the fact is that the developers of the framework are not principally concerned with how popular MooTools is. Our first priority is that the code is of the highest quality that we can make it. We are all still learning, and so this involves many, many refinements in each iteration. We do our best to engage in the community, and I perhaps more so than others (and, to be fair, I rarely commit code to the core – I devote much more of my time to this sort of outreach), but the first priority is developing what we think is the best possible framework that we can.

    Thanks for your feedback. This kind of stuff is always helpful.

  29. The Programmer’s Delima: When and How to Refactor your Codebase » Clientcide (Formerly CNET's Clientside) Says:

    [...] making nearly everything classes I get a lot of benefits that I’ve written about previously (this is worth reading if you haven’t [...]

  30. hixsonj Says:

    Aaron, I’m interested in learning more about that OO style you use with MooTools. Are there any tutorials dedicated to just that? Could you point me in the right direction?

  31. Aaron N. Says:

    I suggest the How to Write a Class and When to Write a Class pages in the mootorial. I also recommend my book (of course), though the 2nd edition will have a lot more in it.

  32. MooTools vs JQuery vs Prototype vs YUI vs Dojo Comparison Revised | Peter Velichkov's Blog Says:

    [...] suggest to read those posts jQuery, MooTools, the Ajax Experience, Programming to the Pattern, and What Really Makes One Framewo… and How Many Flavors of Linux Are There?. A good thing to do is subscribe to his RSS feed since [...]