Hello!
The comments on this profile are unclaimed and thus are unverified.
Do they belong to you? Claim these comments.
Jeff L
Is this you? Claim Profile »
1 month ago
in jqueryvsmootools.com on jQuery vs MooTools
Aaron,
Thanks for taking the time to format whatever needed it in my post. Understand your reasoning about the design pattern of jQuery. Chaining is definitely the intended use, but (for me at least) part of the beauty of jQuery is the fact that you can write the code how you want to see it. So, if you're more comfortable with the verbose notation you can definitely write it that way. Personally I get a kick out of chaining 20 methods together. ;-)
I'm certainly not trying to sell you on jQuery in any way, but want to make sure that anyone who happens across this article doesn't get the wrong impression about what it can or can't do.
BTW, the inheritance model of the classes and subclasses in MooTools seems really cool.
Also, I think it's great you're getting the word out about MooTools, as for some reason, I totally thought it was reliant on Prototype (must have been MooFx I was thinking of).
Thanks for taking the time to format whatever needed it in my post. Understand your reasoning about the design pattern of jQuery. Chaining is definitely the intended use, but (for me at least) part of the beauty of jQuery is the fact that you can write the code how you want to see it. So, if you're more comfortable with the verbose notation you can definitely write it that way. Personally I get a kick out of chaining 20 methods together. ;-)
I'm certainly not trying to sell you on jQuery in any way, but want to make sure that anyone who happens across this article doesn't get the wrong impression about what it can or can't do.
BTW, the inheritance model of the classes and subclasses in MooTools seems really cool.
Also, I think it's great you're getting the word out about MooTools, as for some reason, I totally thought it was reliant on Prototype (must have been MooFx I was thinking of).
1 reply
Rafael B.
jQuery coder here. Still, I do like the inheritance thing and Class thing going on in MooTools.. Thanks for this site whoever you are. Problem is getting everyone to code nice and neat and use the strength of the tools.. how often that happens..
1 month ago
in jqueryvsmootools.com on jQuery vs MooTools
First, let me say this is a nice overview of MooTools and I know that's your forte, not jQuery. That said, I have a few comments regarding your jquery examples. First, a bit of a problem with your "Anything you can do I can do better" example.
You argue that you like the MooTools example better as it's more verbose. Well, you can do the same with jQuery by simply chaining the mouseenter and mouseleave events rather than using hover.
$(document).ready(function() {
$("#orderedlist li:last").mouseenter(function() {
$(this).addClass("green");
}).mouseleave(function() {
$(this).removeClass("green");
});
});
Also, your "Chaining as a design pattern" example you have the same comment - you don't like the syntax of jQuery because you like the MooTools syntax better. Again, you can do the same with jQuery:
var $faq = $('#faq');
$faq.find('dd').hide();
$faq.find('dt').click(function() {
$(this).next().slideToggle();
});
In your ajax example for jquery, you state this:
"This is problematic because this effect is going to go off before our ajax finishes loading."
Again, incorrect. You can use the callback argument to the load() method to call the original plugin, thus making sure your data is loaded before calling the plugin.
Anyway, I know they are both great tools, and I'll definitely put MooTools on my list to check out, but I hope this clears up some of the misconceptions regarding jQuery in your article.
You argue that you like the MooTools example better as it's more verbose. Well, you can do the same with jQuery by simply chaining the mouseenter and mouseleave events rather than using hover.
$(document).ready(function() {
$("#orderedlist li:last").mouseenter(function() {
$(this).addClass("green");
}).mouseleave(function() {
$(this).removeClass("green");
});
});
Also, your "Chaining as a design pattern" example you have the same comment - you don't like the syntax of jQuery because you like the MooTools syntax better. Again, you can do the same with jQuery:
var $faq = $('#faq');
$faq.find('dd').hide();
$faq.find('dt').click(function() {
$(this).next().slideToggle();
});
In your ajax example for jquery, you state this:
"This is problematic because this effect is going to go off before our ajax finishes loading."
Again, incorrect. You can use the callback argument to the load() method to call the original plugin, thus making sure your data is loaded before calling the plugin.
Anyway, I know they are both great tools, and I'll definitely put MooTools on my list to check out, but I hope this clears up some of the misconceptions regarding jQuery in your article.
1 reply
anutron
Hi Jeff,
I edited your post to try and clean up the formatting. Disqus won't let me add pre tags around things so I ended up having to put in a bunch of nbsp-s in there.
Anyway to respond to your points, I'll first note that I used jQuery's own examples in these cases. You're totally right though; I know MooTools inside and out and I can't say that about jQuery. I did spend a lot of time in preparing this article reading through the jQuery core, reading tutorials, looking at the source of plugins, etc. in an effort to understand how jQuery is used. The examples I chose were examples jQuery offers in its own tutorials, so I felt confident that they were the inended use. jQuery provides its hover method as the intended way to manage mouseover and out behavior. jQuery also provides example of example where the design pattern is to re-use selectors instead of caching query results into variables. While it's possible to write code in numerous ways (it's all a subset of JavaScript after all) this is not the design pattern that jQuery is espousing.
Part of what makes jQuery so accessible is it's ability to feel a lot like CSS. Everything in jQuery is attached to a CSS expression, and it's this pattern that makes it so easy for newcomers to the world of JavaScript, newcomers who have experience building HTML and CSS pages, to dive right into jQuery. It's part of what makes jQuery work well and the size of the jQuery user base is a testament to it. My argument is that, as a programmer - one who really likes JavaScript to begin with, I prefer an API that looks more like JavaScript.
But that's the whole argument of this article. That I can prefer one thing and others can prefer other things. For instance, I saw this tweet earlier this evening where someone is basically saying that this article only affirmed their choice for jQuery, and that's great. The purpose of this article is to help explain how the design patterns of these two libraries are different so that people can make more informed choices. While it's true that I prefer MooTools, and yes that shows through in this article, I tried my best to show both frameworks in the positive light they deserve. Part of doing that is expressing these examples in the way the languages each prefer you write them. As I mentioned in the article, you can download a plugin for MooTools that emulates all of jQuery's behavior. Because jQuery is all written in JavaScript, it's possible to write it in ways that look like jQuery. But neither framework suggests you do that (I certainly don't - if you like the syntax of MooTools, use it. If you like the syntax of jQuery, then use that). So instead I focused on trying to represent these frameworks' design patterns as they prescribe them.
Thanks for the feedback. I've been impressed thus far with the quality and thoughtfulness of the comments left here.
I edited your post to try and clean up the formatting. Disqus won't let me add pre tags around things so I ended up having to put in a bunch of nbsp-s in there.
Anyway to respond to your points, I'll first note that I used jQuery's own examples in these cases. You're totally right though; I know MooTools inside and out and I can't say that about jQuery. I did spend a lot of time in preparing this article reading through the jQuery core, reading tutorials, looking at the source of plugins, etc. in an effort to understand how jQuery is used. The examples I chose were examples jQuery offers in its own tutorials, so I felt confident that they were the inended use. jQuery provides its hover method as the intended way to manage mouseover and out behavior. jQuery also provides example of example where the design pattern is to re-use selectors instead of caching query results into variables. While it's possible to write code in numerous ways (it's all a subset of JavaScript after all) this is not the design pattern that jQuery is espousing.
Part of what makes jQuery so accessible is it's ability to feel a lot like CSS. Everything in jQuery is attached to a CSS expression, and it's this pattern that makes it so easy for newcomers to the world of JavaScript, newcomers who have experience building HTML and CSS pages, to dive right into jQuery. It's part of what makes jQuery work well and the size of the jQuery user base is a testament to it. My argument is that, as a programmer - one who really likes JavaScript to begin with, I prefer an API that looks more like JavaScript.
But that's the whole argument of this article. That I can prefer one thing and others can prefer other things. For instance, I saw this tweet earlier this evening where someone is basically saying that this article only affirmed their choice for jQuery, and that's great. The purpose of this article is to help explain how the design patterns of these two libraries are different so that people can make more informed choices. While it's true that I prefer MooTools, and yes that shows through in this article, I tried my best to show both frameworks in the positive light they deserve. Part of doing that is expressing these examples in the way the languages each prefer you write them. As I mentioned in the article, you can download a plugin for MooTools that emulates all of jQuery's behavior. Because jQuery is all written in JavaScript, it's possible to write it in ways that look like jQuery. But neither framework suggests you do that (I certainly don't - if you like the syntax of MooTools, use it. If you like the syntax of jQuery, then use that). So instead I focused on trying to represent these frameworks' design patterns as they prescribe them.
Thanks for the feedback. I've been impressed thus far with the quality and thoughtfulness of the comments left here.
