one of the reasons jquery is more popular is because of "plugins" and notable websites writing tutorials on jguery (ie. web designer wall & nettuts) in that respect jquery is alot easier to pickup
Alan
· 1 year ago
I'm not familiar with MooTools but I can dig your criticisms of jQuery. I'll have to check it out.
atom
· 1 year ago
I love MooTools. It is definitely my default framework. I agree with pretty much every point you have made here, with the exception of the speed. I don't think it is easy to say that it is the fastest based on slickspeed.
Try using it repeatedly and in different browsers, the results vary enough for it to be "fast" but not "faster".
It should also be kept in mind that slickspeed is a selector test. It would be very difficult to make a full on library vs library test.
Michael Schoonmaker
· 1 year ago
I don't know about number 3. I just ran those tests, and I'm getting jQuery in the lead. Granted, they each have only 1 "slower" test, but more often, jQuery is faster.
On another note, I'm going to have to try Mootools, if only because OOP is involved. I'm not saying jQuery needs it, but I'm so used to it as a software engineer that it would be interesting to see used in javascript.
mike taylor
· 1 year ago
re: # 3 i'm not convinced by the speed results. one to one, jquery performed better on more tests than mootools. overall, mootools did slightly better, but dojo wasted them both.
but honestly, are you going to use that many selectors on any given page?
either way, this comparison isn't that great of a metric.
also, re: #5, var el = new Element(‘a’, { ‘href’: ‘juliocapote.com’}); try $('a').attr('href', 'juliocapote.com'). and then chain that with .appendTo().
done.
Greg Wolejko
· 1 year ago
#6 is a total advantage of MooTools (beside other)
on a daily basis I don't create sites that require me to use *every* method/functionality that a framework allows. In fact I don't believe there are that many who do :)
The ability to create your own small package of MooTools absoutely rocks when resource sizing is an issue
httpwebwitch
· 1 year ago
I agree. Mootools has changed the way I script; I've used it for over a year to build a series of huge client-side applications - I wonder how I ever got along without it.
Joomla Developer
· 1 year ago
Mootools transitions are excellent. There's a million tutorials and example code around the net and it is simple to implement. My CMS of choice - Joomla! - now includes the mootools library in it's core which is great. In the past plugin developers were all using different libraries and packaging them with the plugins and it was often causing all sorts of conflicts. Now, it's mootools all the way.
digitarald
· 1 year ago
Kodus on that entry, I like your point of views! If you have to change existing jQuery behaviour one time, you'll see how hard that is because of its design philosophies ... then you miss OOP and convert to MooTools.
But that happened only one time and I could convert my clients requirements to MooTools too ;-)
rexxars
· 1 year ago
I agree with most of these points. The speed issue doesn't really matter to me, as they both seem to be pretty much equally fast (faster and slower in different areas).
Mootools code is prettier. It's much easier to read and I personally enjoy everything being prototyped (extended) instead of having to rely on a namespace. It just feels more natural, like an empowerment of Javascript.
I think what MooTools really needs is a class/plugin type of repository/forge (I know multiple people are working on this... why don't you combine your efforts and make one "official" place? It would be much better for the community as a whole, IMO).
I've been wanting to write a couple of points on why I prefer mootools over jQuery myself, now I can refer people to this instead :-)
Anders Borum
· 1 year ago
I have to agree with most of the points (again also pointing out that speed is not everything but nice to see that mootools is best or second in most of the tests from #3).
Mootools have really encouraged me to start doing rich client side development again; it's just that easy - add to that the community is excellent on helping out (you can find me in the #mootools channel on irc.freenode.net (6667)).
Matthew Donadio
· 1 year ago
I would argue that the modular aspect isn't necessarily a strength. The roll-you-own builds can save bandwidth, etc, but I think long-term maintainability of the site suffers, especially if another developer (or less experienced person) has to pick up the project.
For example, another developer who sees moo.js being loaded may incorrectly assume that certain functionality is present. This isn't an earth shattering problem, but I think as developers we should do our best to prevent these situations (especially when doing work for a client).
Nathan Querido
· 1 year ago
Very concise and I agree with you 100%. I am not a Javascript developer myself, so jQuery in theory should actually suite me better being a designer. But from a pure design perspective, MooTools is beautiful generally. The whole project, from the website, to the docs, have been thought through. It's in the details!
Carlos
· 1 year ago
Why not extJS? or Why not YUI? this are never ending topics...
marcoslhc
· 1 year ago
you nailed it. This is a discussion about which library fits with each person, like "which color suits me best?" kind of thing
Buzu
· 1 year ago
Should I write "Why Javascript (Or why neither MooTools nor JQuerry)"
Artem
· 1 year ago
Accidentally found this post and figured I'd throw in my 2 cents with a tiny bit of history.
For the past year and a half I have been using MooTools almost exclusively. I recently began working for a new company and was pretty stoked they used jQuery regularly. I only played with jQuery in small amounts prior to this and understood JavaScript really well, so I was welcoming of the learning experience.
After working with jQuery extensively and deploying several projects, I can honestly say that I have never had such headaches with JavaScript until I started using jQuery. I've pretty much convinced my employer to begin using MooTools for future projects and they even let me build a few great Moo plugins for fun (and usefulness, of course). I can't wait to stop using jQuery.
Here's my list of problems with jQuery:
1) Need a plugin here. Need a plugin there. Binding objects to an event? Argh, need a plugin. Ah gotta get the absolute position of an element relative to another element... *sigh*.. gotta find a plugin. Need to parse this JSON string that wasn't part of an XHR request... wow.. I need a plugin. Plugin, plugin, plugin. How many freaking plugins do I have to find and download before I can actually get substantial use out of jQuery? Also, how reputable are these plugin developers? Do people honestly believe that maintaining a library written by 50 different people (49 plugins, 1 jQuery) who do not work together or follow the same coding standard is normal? So if 8 of the 49 plugins I need to run web application with a powerful front end update versions due to bug fixes -- how will I know this? Do I have to keep tabs on them? Yea, I didn't think so. jQuery has less functionality than MooTools core alone (MooTools Core is 60kb compressed with YUI).
jQuery + Plugins = unmaintainable BLOAT.
MooTools has a great library that does far more than jQuery does by default. This means the developers of MooTools took into consideration these features when writing the library. It also means the library is optimized to use these features. (ie: In certain cases Moo devs could mangle the internal structure just a little bit to get things working faster). The developers won't notice since its deep in the internal workings of the library -- but you can speed increases.
In jQuery, even the simplest of things aren't supported out of the box which means I have to download a plugin written by some guy in his basement and put it into production for my client -- kind of risky don't you think? Especially since most of these plugins go through multiple phases of release for a couple months and then support quickly dies out while some bugs go undiscovered for a long time.
2) jQuery still uses JS Packer... why? Check out this link and compare your compressed code with YUI compressor vs Packer: http://compressorrater.thruhere.net/
Sure I can compress with my choice of compressor but the fact the jQuery uses packer by default means many users will too. Code compressed with Packer is slower. This means if I have to work with someone else's jQuery code chances are they packed the library and all associated plugins, which results in more work for me trying to convince them to use YUI compressor and actually going through and recompressing everything.
3) The code written in jQuery is completely unmaintainable until you start coding it the MooTools way and then once you do, you'll quickly realize jQuery doesn't have the legroom for maintainable code.
Is it possible to tell from looking at the code what exactly this thing does? The code is a mess. Now multiply this by 100 and imagine the front end part of a web application ... more like the "back-end" part if you ask me :)
I mean seriously: (function($){ // lolcopter what is this? });
4) jQuery does not provide the lovely custom events MouseEnter and MouseLeave that MooTools does. Oh now wait... yes it does, but it isn't documented. Oh now wait... it is documented but under MouseOver... huh? I wonder what other secrets I will uncover :)
5) jQuery only has one utility function for strings. To capitalize some text (a very common task) I have to go out and find a plugin or write it myself. I spend more time hunting for plugins or writing my own than time I save by writing $('#myDiv') instead of document.getElementById('myDiv')
6) All the stuff the original poster said.
Michael
· 1 year ago
Cool article! But:
its faster -> it's faster it's magic -> its magic
Kwame
· 1 year ago
Both frameworks are great for different situations. Mootools is perfect when you are coding a robust (read large) js solution from scratch while jQuery plays nicely with existing js. Most of the features are the same, however, MooTools augments the Javascript language in many ways (by altering and improving the functionality of native objects) while jQuery is a library in the traditional sense. If you are looking to code some super custom object and you need a lot of the MooTools More and Core go with that but if you just want easier DOM management and some cool effects go with jQuery.
ok 1. JS does not need any class support, because it has - work with object cloning, not instantiation. 2. Yes, maybe 5. Do like this: jQuery('<div class="someclass"></div>') 6. Yes mootools wins here 7. It is subjective thing - I like more jquery docs 9. It is evil - IE6 leaks well 10. jQuery is only better than mootools, not a revolution
Catar4x
· 1 year ago
Mootools power ! I love this framework because they are less mistakes with the "onload" function by it.
Nathan L Smith
· 1 year ago
I don't see the point in arguing over which framework is "better". There's room for all of them and they each have different goals and approaches. Sure some comparison is fine but this seems like trying to point out where jQuery is "wrong" where it's just different then Mootools.
I like them both, but I like Prototype.js better, so there.
dfguy
· 1 year ago
you're wasting you time. jQuery is now backed by Microsoft and Nokia. Pretty soon it will become that defacto standard in javascript and ajax development. I can forsee that Adobe will adopt it into CF soon. All other javascript frameworks will soon fade into the void.
Dan
· 10 months ago
Adobe already has Spry, so chances are slim of them using jQuery.
issackelly
· 1 year ago
I'm going to do a point by point here.
1) "Eventually you'll want real classes to structure your UI logic". While This is what you want, the better I get at jQuery the more I use chaining. I also lean toward functional programming and not OO programming, so...yeah. I'm just saying that this isn't necessarily a global drawback as much as a design choice. 2) Ok, I buy that, but again, I see it as a preference thing, because before jQuery, to me 'regular javascript' just wasn't that good 3) Yeah.. you figured this one out (and Webkit Nightly does EVERYTHING faster, it's great...I can't wait for the mainstream version of that) 4) I don't do animations much.. but in my experience jQuery's have been...sufficient. Moo Tools animations do look pretty good 5) $("done"); 6) You can do this from SVN...but at 12kbs I think it's really unnecessary 7) I've never checked out the mootools documentation, My experience with jQuery doc has been very good, and my experience with the #jquery on irc.freenode.net has been very good as well 8) I haven't done anything outside of 'basic usage' with mootools, but jquery isn't an 'unintelligible mess' by any means. 9) Yeah, this is just preference, but unobtrusive is worth it, especially if you have to have two versions of the same library on a page. 10) I for one welcome our new namespaced overlords.
Ya, MooTools is a nice set of tools. But, I prefer prototype.js.
My reasoning: It has a number of methods that are not available with MooTools. It has better documentation (really easy to find on their api page).
Though, MooTools has some features that prototype doesn't. Like the getScrollSize() method, and all of the snazzy effects (which are nice). For those effects you could go with script.aculo.us, but the MooTools effects do seem better (+ smoother).
Will
· 1 year ago
I used to use Mootools however I dropped it after bugs with select box .selectedIndex in Safari. I hacked some of the mootools source to fix it, but I don't want to run a customized version on a production server due to upgrade concerns. On a side note, it took mootools over a year to go from 1.11 to 1.2.
I've had way better luck with jQuery. I haven't run into any show-stopping bugs (actually, none at all), and even if I did the releases are much more frequent .
Jonathan Fenocchi
· 1 year ago
You're right. jQuery doesn't look a thing like JavaScript. Thank heavens! JavaScript about three or four years ago was perhaps the ugliest code ever, excluding perhaps VB.
I write all of my JavaScript as if it were a jQuery or Greasemonkey script nowadays, even if I'm not using a library. Unobtrusive, graceful degradation, accessibility, speed, and the benefit of beautiful, structured code. I have used probably every JavaScript library at some point. Prototype was my favorite when it came out, then MooTools, and now it's jQuery. I'll never go back. =)
Graham Jenson
· 1 year ago
I have used jQuery a little, and interested now to at least try mooTools(personally I hate JavaScript with a passion so 2 is actually a turn off) I just have one problem with this post however... #6 Modular By definition of the title it implies that it is in modules, but you say that it is all in one class, this is then a misnomer. I agree having all the functionality in a single class has its pros and cons vs many classes, BUT, that is not modularity, it is more like singleton. If mooTools can be extended then that would be the reason for arguing for modularity, but not the single file thing.
Graham
Graham Jenson
· 1 year ago
Oh I see, you can build your own moo.js from a greater set of functionality. That makes more sense, great little idea. More research is needed I think.
@Julio: Thanks for your feedback. We totally respect your decision but I will leave you with this. The simple fact that John reached out to you for your feedback is indicative of how much we (the jQuery team) care about the community of developers. That, in itself, sets us apart from most projects and is a HUGE reason why people love jQuery.
Your choice of framework is a very personal decision and we just want to let you know that we appreciate you using jQuery and we're here to help if you need us.
Rey Bango jQuery Team
Tom Occhino
· 1 year ago
I posted this previously but thought it couldn't hurt to reiterate. :)
I think it's important for everyone to remember, the JavaScript libraries and frameworks aren't competing... We aren't at war with each other, we are all collectively at war against browser inconsistencies, and limitations of the JavaScript language itself.
Since all the framework authors understand this, I think it's important for us to start conveying to our users how important it is for them to understand it as well.
That being said, choose the framework you think is best for the job, and squeeze all the functionality you can out of it ;)
existdissolve
· 1 year ago
I agree with the first comment. The whole "my javascript framework is better than yours" is juvenile--the best javascript framework, scripting language, graphic editing program, etc. is the one that helps you best create awesome projects for your clients. Period.
Webdesign Meppel
· 1 year ago
First of all, I like them both. I once started with Mootools and build a site with it using the scrolling function (http://www.hapjestheater.nl). Some time later I got known to jQuery and now I can say it fits my needs better. I've never been very good with javascript and jQuery seems to be more understandable to me.
But as I said, the're both great frameworks!
Allan
· 1 year ago
I am just a web designer... but I fond jQuery easy to understand that other javascript library
kcmr
· 1 year ago
I agree.
surajnaikin
· 1 year ago
Well all the dicussion here is cool..but would like to say something.. "Advanced doesn't means the best", there are websites without any JS included runs as good as with some JS frameworks. Many a times i switch off JS in my browser which completely distorts the page. Do we give a thought what if a user blocks the JS, will the website will run with a lot of JS included for what not effects, Dont you all thinnk we are so much tend to use JS as something different which is not always required. Can we found a way where in all this is a part of plain HTML itself..Sounds little negative?
cpojer
· 1 month ago
Hello,
I like the list you came up with. Please note that I think the scope of our project is much bigger, you cannot just compare jQuery and MooTools like that. MooTools just happens to have functionality that is similar to that of jQuery's (Element, Fx, Request) because it is generally needed when programming on the clientside.
In the near future we will try to make everything even better, just stay tuned for the changes. Btw. it is the first time ever someone said that our documentation is better. Maybe you just think like we do, care to get involved? ;)
Bye
jperras
· 1 year ago
For #1: Javascript is a Prototype-based language, not a classical class-based inheritance language. Using classes may seem intuitive to people who have never used prototypes, but this masks the true beauty of Javascript.
Douglas Crockford's "Javascript: The Good Parts" is one of the best references I can recommend.
For #9: Extending native prototypes is great in principle, but can lead to incompatibilities where you never expected them. Try dropping MooTools into a legacy project that relies heavily on plain-old javascript. Namespacing is the only way to avoid this pitfall, and jQuery does it masterfully.
Sinisa Tomac
· 1 year ago
I just have to back up on this comment. I'm using both mootools (with joomla sites) and jquery on JSF based projects. I suppose mootools may be nicer (both code and effects) but jquery works in conjuction with other javascript frameworks where mootools have failed me.
marcoslhc
· 1 year ago
I've never used mooTools. But I have some replies to say about two of the critics you made to jquery. About the "Class Support", JavaScript (or ECMAScript) is a Object Oriented Language, but its object model is not "Classical" it's "prototypical". For many years people tried to use and teach Javascript as kinda subset of Java or C++ but, in fact, the philosophy behind JavaScript is totally different. It was meant to extend the behavior of a client app like the browser, so you don't really need classes with native data types, you just need Objects that extends functionality established in the DOM prototypes or the browser prototypes. In this philosophy is important also to bind names and make callbacks 'cause you never work with native data files on client machines (except for cookies with their limited uses), they are an efficient way to work further with data after it have been sent and previously manipulated. The "chain" (or what you call "SQL-like sintax") is actually a real good way to represent and understand the nature and function of binds and callbacks. About the "Prototype Approach", I think in the long term, specially if you work in a team having unobtrusive code is way too important, even more important than file sizes, it's a matter of scalability. I will defend jquery in this saying that more than a function library, jquery is a Framework with its own model and methodology, it have its own method to apply and extend the models and functions proposed by its author. That's why the whole namespace and wrapping thing. If you want "shorter, natural code" stick with a library with "Prototype Approach", if you want a team-friendly environment to develop scalable javascript interfaces and applications, a framework with its own namespace.
All Comments
Try using it repeatedly and in different browsers, the results vary enough for it to be "fast" but not "faster".
It should also be kept in mind that slickspeed is a selector test. It would be very difficult to make a full on library vs library test.
On another note, I'm going to have to try Mootools, if only because OOP is involved. I'm not saying jQuery needs it, but I'm so used to it as a software engineer that it would be interesting to see used in javascript.
i'm not convinced by the speed results. one to one, jquery performed better on more tests than mootools. overall, mootools did slightly better, but dojo wasted them both.
but honestly, are you going to use that many selectors on any given page?
either way, this comparison isn't that great of a metric.
also, re: #5,
var el = new Element(‘a’, { ‘href’: ‘juliocapote.com’});
try
$('a').attr('href', 'juliocapote.com'). and then chain that with .appendTo().
done.
on a daily basis I don't create sites that require me to use *every* method/functionality that a framework allows. In fact I don't believe there are that many who do :)
The ability to create your own small package of MooTools absoutely rocks when resource sizing is an issue
But that happened only one time and I could convert my clients requirements to MooTools too ;-)
Mootools code is prettier. It's much easier to read and I personally enjoy everything being prototyped (extended) instead of having to rely on a namespace. It just feels more natural, like an empowerment of Javascript.
I think what MooTools really needs is a class/plugin type of repository/forge (I know multiple people are working on this... why don't you combine your efforts and make one "official" place? It would be much better for the community as a whole, IMO).
I've been wanting to write a couple of points on why I prefer mootools over jQuery myself, now I can refer people to this instead :-)
Mootools have really encouraged me to start doing rich client side development again; it's just that easy - add to that the community is excellent on helping out (you can find me in the #mootools channel on irc.freenode.net (6667)).
For example, another developer who sees moo.js being loaded may incorrectly assume that certain functionality is present. This isn't an earth shattering problem, but I think as developers we should do our best to prevent these situations (especially when doing work for a client).
this are never ending topics...
For the past year and a half I have been using MooTools almost exclusively. I recently began working for a new company and was pretty stoked they used jQuery regularly. I only played with jQuery in small amounts prior to this and understood JavaScript really well, so I was welcoming of the learning experience.
After working with jQuery extensively and deploying several projects, I can honestly say that I have never had such headaches with JavaScript until I started using jQuery. I've pretty much convinced my employer to begin using MooTools for future projects and they even let me build a few great Moo plugins for fun (and usefulness, of course). I can't wait to stop using jQuery.
Here's my list of problems with jQuery:
1) Need a plugin here. Need a plugin there. Binding objects to an event? Argh, need a plugin. Ah gotta get the absolute position of an element relative to another element... *sigh*.. gotta find a plugin. Need to parse this JSON string that wasn't part of an XHR request... wow.. I need a plugin. Plugin, plugin, plugin. How many freaking plugins do I have to find and download before I can actually get substantial use out of jQuery? Also, how reputable are these plugin developers? Do people honestly believe that maintaining a library written by 50 different people (49 plugins, 1 jQuery) who do not work together or follow the same coding standard is normal? So if 8 of the 49 plugins I need to run web application with a powerful front end update versions due to bug fixes -- how will I know this? Do I have to keep tabs on them? Yea, I didn't think so. jQuery has less functionality than MooTools core alone (MooTools Core is 60kb compressed with YUI).
jQuery + Plugins = unmaintainable BLOAT.
MooTools has a great library that does far more than jQuery does by default. This means the developers of MooTools took into consideration these features when writing the library. It also means the library is optimized to use these features. (ie: In certain cases Moo devs could mangle the internal structure just a little bit to get things working faster). The developers won't notice since its deep in the internal workings of the library -- but you can speed increases.
In jQuery, even the simplest of things aren't supported out of the box which means I have to download a plugin written by some guy in his basement and put it into production for my client -- kind of risky don't you think? Especially since most of these plugins go through multiple phases of release for a couple months and then support quickly dies out while some bugs go undiscovered for a long time.
2) jQuery still uses JS Packer... why? Check out this link and compare your compressed code with YUI compressor vs Packer:
http://compressorrater.thruhere.net/
Sure I can compress with my choice of compressor but the fact the jQuery uses packer by default means many users will too. Code compressed with Packer is slower. This means if I have to work with someone else's jQuery code chances are they packed the library and all associated plugins, which results in more work for me trying to convince them to use YUI compressor and actually going through and recompressing everything.
3) The code written in jQuery is completely unmaintainable until you start coding it the MooTools way and then once you do, you'll quickly realize jQuery doesn't have the legroom for maintainable code.
Here's a plugin I was recently asked to implement:
http://jdsharp.us/jQuery/plugins/jdMenu/1.4.1/j...
Is it possible to tell from looking at the code what exactly this thing does? The code is a mess. Now multiply this by 100 and imagine the front end part of a web application ... more like the "back-end" part if you ask me :)
I mean seriously:
(function($){
// lolcopter what is this?
});
4) jQuery does not provide the lovely custom events MouseEnter and MouseLeave that MooTools does. Oh now wait... yes it does, but it isn't documented. Oh now wait... it is documented but under MouseOver... huh? I wonder what other secrets I will uncover :)
5) jQuery only has one utility function for strings. To capitalize some text (a very common task) I have to go out and find a plugin or write it myself. I spend more time hunting for plugins or writing my own than time I save by writing $('#myDiv') instead of document.getElementById('myDiv')
6) All the stuff the original poster said.
its faster -> it's faster
it's magic -> its magic
var el = $("");
1. JS does not need any class support, because it has - work with object cloning, not instantiation.
2. Yes, maybe
5. Do like this: jQuery('<div class="someclass"></div>')
6. Yes mootools wins here
7. It is subjective thing - I like more jquery docs
9. It is evil - IE6 leaks well
10. jQuery is only better than mootools, not a revolution
I love this framework because they are less mistakes with the "onload" function by it.
I like them both, but I like Prototype.js better, so there.
1) "Eventually you'll want real classes to structure your UI logic". While This is what you want, the better I get at jQuery the more I use chaining. I also lean toward functional programming and not OO programming, so...yeah. I'm just saying that this isn't necessarily a global drawback as much as a design choice.
2) Ok, I buy that, but again, I see it as a preference thing, because before jQuery, to me 'regular javascript' just wasn't that good
3) Yeah.. you figured this one out (and Webkit Nightly does EVERYTHING faster, it's great...I can't wait for the mainstream version of that)
4) I don't do animations much.. but in my experience jQuery's have been...sufficient. Moo Tools animations do look pretty good
5) $("done");
6) You can do this from SVN...but at 12kbs I think it's really unnecessary
7) I've never checked out the mootools documentation, My experience with jQuery doc has been very good, and my experience with the #jquery on irc.freenode.net has been very good as well
8) I haven't done anything outside of 'basic usage' with mootools, but jquery isn't an 'unintelligible mess' by any means.
9) Yeah, this is just preference, but unobtrusive is worth it, especially if you have to have two versions of the same library on a page.
10) I for one welcome our new namespaced overlords.
.."Not that it doesn't stand up on its own right, but I have to throw my $0.02 in"
My reasoning:
It has a number of methods that are not available with MooTools.
It has better documentation (really easy to find on their api page).
Though, MooTools has some features that prototype doesn't. Like the getScrollSize() method, and all of the snazzy effects (which are nice). For those effects you could go with script.aculo.us, but the MooTools effects do seem better (+ smoother).
I've had way better luck with jQuery. I haven't run into any show-stopping bugs (actually, none at all), and even if I did the releases are much more frequent .
I write all of my JavaScript as if it were a jQuery or Greasemonkey script nowadays, even if I'm not using a library. Unobtrusive, graceful degradation, accessibility, speed, and the benefit of beautiful, structured code. I have used probably every JavaScript library at some point. Prototype was my favorite when it came out, then MooTools, and now it's jQuery. I'll never go back. =)
I just have one problem with this post however...
#6 Modular
By definition of the title it implies that it is in modules, but you say that it is all in one class, this is then a misnomer. I agree having all the functionality in a single class has its pros and cons vs many classes, BUT, that is not modularity, it is more like singleton.
If mooTools can be extended then that would be the reason for arguing for modularity, but not the single file thing.
Graham
Graham
Your choice of framework is a very personal decision and we just want to let you know that we appreciate you using jQuery and we're here to help if you need us.
Rey Bango
jQuery Team
I think it's important for everyone to remember, the JavaScript libraries and frameworks aren't competing... We aren't at war with each other, we are all collectively at war against browser inconsistencies, and limitations of the JavaScript language itself.
Since all the framework authors understand this, I think it's important for us to start conveying to our users how important it is for them to understand it as well.
That being said, choose the framework you think is best for the job, and squeeze all the functionality you can out of it ;)
Some time later I got known to jQuery and now I can say it fits my needs better. I've never been very good with javascript and jQuery seems to be more understandable to me.
But as I said, the're both great frameworks!
I like the list you came up with. Please note that I think the scope of our project is much bigger, you cannot just compare jQuery and MooTools like that. MooTools just happens to have functionality that is similar to that of jQuery's (Element, Fx, Request) because it is generally needed when programming on the clientside.
In the near future we will try to make everything even better, just stay tuned for the changes. Btw. it is the first time ever someone said that our documentation is better. Maybe you just think like we do, care to get involved? ;)
Bye
Douglas Crockford's "Javascript: The Good Parts" is one of the best references I can recommend.
For #9: Extending native prototypes is great in principle, but can lead to incompatibilities where you never expected them. Try dropping MooTools into a legacy project that relies heavily on plain-old javascript. Namespacing is the only way to avoid this pitfall, and jQuery does it masterfully.
About the "Class Support", JavaScript (or ECMAScript) is a Object Oriented Language, but its object model is not "Classical" it's "prototypical". For many years people tried to use and teach Javascript as kinda subset of Java or C++ but, in fact, the philosophy behind JavaScript is totally different. It was meant to extend the behavior of a client app like the browser, so you don't really need classes with native data types, you just need Objects that extends functionality established in the DOM prototypes or the browser prototypes. In this philosophy is important also to bind names and make callbacks 'cause you never work with native data files on client machines (except for cookies with their limited uses), they are an efficient way to work further with data after it have been sent and previously manipulated. The "chain" (or what you call "SQL-like sintax") is actually a real good way to represent and understand the nature and function of binds and callbacks.
About the "Prototype Approach", I think in the long term, specially if you work in a team having unobtrusive code is way too important, even more important than file sizes, it's a matter of scalability. I will defend jquery in this saying that more than a function library, jquery is a Framework with its own model and methodology, it have its own method to apply and extend the models and functions proposed by its author. That's why the whole namespace and wrapping thing. If you want "shorter, natural code" stick with a library with "Prototype Approach", if you want a team-friendly environment to develop scalable javascript interfaces and applications, a framework with its own namespace.
http://rivals4ever.com/view_rivalry.php?r_id=68...
Cast your opinions here!