Hi Xandros, There are two things here that I think deserve comment. First, David Mark makes a lot of broad claims about the work of many developers, posting long rants about anything that any JS framework team has ever posted. If you look for his other posts on the usenet you'll find similar rants about Prototype, jQuery, YUI and others. He has his own definition of what good javascript is and he is entitled to it, but that does not mean he is right. Rather, he seems to enjoy spending tremendous amounts of effort harshing on the work and progress made by others, which while probably enjoyable to him, isn't helpful to anyone and doesn't enable others to do interesting things on the web. I think that, regardless of what you think of the code quality of any particular framework, we can all agree that their presence has enabled the web to move forward. The web is a far more interactive and dynamic place because of frameworks like MooTools and jQuery, and even if you disagree with their style or syntax, you can't argue that people have not made interesting things with them.
Consequently I'm content to focus on making MooTools better and building interesting things with it (and helping others to do so). MooTools isn't perfect - which is why we're always working on it - but spending our time responding to line-by-line ranting from the likes of David Marsh is not going to help us make it any better. Most of his complaints have to do with style. He hates the use of $ in method names, he thinks that having a semi-colon at the end of a line that precedes the end of a function, loop, or conditional is an error, stuff like that. He rails against methods he doesn't think are useful and in general just finds specious arguments for nearly every line of code he didn't write. There's no profit in engaging with a fellow like this. The second thing worth commenting on is what you wrote here: the low level classes and functions of > Mootools are getting bigger and more and more complicated with lots of > strange code that is dependant on a lot of other strange code, and in > the end we just get the same behaviour as before, enhanced a bit of > course. > What you are arguing against here is abstractions. We can write code that is very literal in nature and, consequently, easy to read and understand. But MooTools follows the DRY principle - Do not Repeat Yourself. When we have two places that need similar logic, we abstract that logic into something both places can use. When we do this, we end up with an abstract piece of code that often looks bizarre. Almost all of the time this is internal code and not exposed to you, the user, to interact with because it wouldn't be useful to you to use. MooTools keeps code like this inside of closures to limit that exposure and we do not document these methods to make it clear that this is internal stuff. Reading through the source of MooTools can be a great way to learn how some of the more complex things in JavaScript work, but you'll occasionally encounter abstractions that might look useless or, at the very least, overly complex and unintelligible. If you spend the time to pick them apart you'll find that they do actually accomplish something, often something rather elegant, and that they usually enable you to do interesting things in the APIs we expose. For instance, the code that allows you to implement methods on Arrays, Functions and Strings has a lot of abstractions that enable you to extend those native objects as you like. So when you see things that look complicated and strange, this isn't an argument that they do not belong there. Aaron On Thu, Sep 3, 2009 at 4:32 AM, Xandros <[email protected]> wrote: > > Hello > > Not wanting to start a flame war, and using myself mootools for a > while, I stumbled on that thread on a developer forum. > A quite harsh critique of Mootools, but the general idea is true, > since the 0.7 versions or so, the low level classes and functions of > Mootools are getting bigger and more and more complicated with lots of > strange code that is dependant on a lot of other strange code, and in > the end we just get the same behaviour as before, enhanced a bit of > course. > > I would really love some Mootools developers to answer here what they > think about this analysis of the code and why ... everybody has got > something to learn from constructive discussion I think ... > > http://www.developersdex.com/asp/message.asp?p=2978&r=6521331 >
