18:33 June 3, 2011


I read about 2/3 of this....he's just starting on how to use Class now, which might actually be interesting, but I don't think I can read anymore. While nothing he says is "wrong" per se, and he even invites jQuery authors to fact-check him, he (I can only presume its a he based on language and tone) presents his opinions as if they are valid and correct and conversely that others are invalid. In some parts, I agree with what he is saying. For instance, it would be nice to have a JS something that extended native objects and made inheritence easier. However, to contend, as he seems to, that since jQuery doesn't do this it is therefore not particularly worth considering I find as horribly invalid. Hey, I have my opinions too.

He presents jQuery as a toolkit and mootools as a framework. I've come to loathe the latter term and, thereby, develop affection for the former. When asked what web framwork I like, my answer remains "none of them". A framework, in experience (and I suppose partially in definition), presents a "do things our way and you'll solve the problem we tell you you want to solve". A bit unfair perhaps, but largely true. To name a very frameworky framework, take django. Answers to a few questions:

Etc. Frameworks are dogmatic. If your dogma meshes with the frameworks, or if you don't care, you're probably fine. For instance, if your questions are like "What template system should I use?", django has an excellent answer: "Ours." Or to put it from a more utilitarian perspective, if you're programming something, you probably have something to do. If you're just playing around, fine, it doesn't really matter if you use esoteric language A on esoteric platform because there aren't any design considerations for your software. Interesting problems usually have design constraints. I could easily invoke economics, but I don't even need to. Even if you're a hobbyist and you don't expect many -- maybe even any -- people other than you to use your software, you still have design constraints if, say, you're making a federated bookmark site. You probably don't want spam. You probably need it to work on a standard browser. You probably don't want it to break if you throw unicode at it. You probably want it easy to deploy and maintain. Maybe you don't. Maybe you enjoy complex and fragile deployments. But probably not. Those are pretty low bars, but its not a horrible example. So you make technology choices to do what you want. Most people don't like reinventing the wheel just for fun. If there is a clear, free, OOTB solution that fits your needs, most people will go for it. Software that I don't have to think about is generally software I like. But, failing that, you have to do it yourself.

The first thing you have to do is decide A. what the problem is; and B. what your solution to the problem will look like. If your problem is making software to organize your bookmarks, well, that's a clear problem :) But this really doesn't give a solution. That's where creativity comes in. You think: "What would it look like if my bookmarks are organized?" Several things flash to mind. If you're an experienced designer, you realize that even if your vision is implemented perfectly, it will probably just point to other problems that you didn't even realize you had, or more optimistically, opportunities and ways of intuiting the universe that you were previously unaware existed. So given that, you set down to write it.

The first thing you do is make technology choices: languages, libraries, platforms, etc. Usually you'll use tools that you know if they apply cleanly (unless, again, your real problem is "I want to learn erlang" and the project is semi-incidental). Herein comes the problem. You've imagined your solution. You can program it with these tools. But how much do you work against the grain of the technologies your working with?

Frameworks, as the word is popularly used, work great when you're going with the grain of the technology. If your vision is served by a regex-based dispatcher interfacing with an SQL database with static files served by (e.g.) Apache that is a traditional-type website with an admin panel, then django may work very well for you. If, on the other hand, you're using a graph database with a highly configurable traversal-based dispatcher with in-memory caching of a small set of static files that will work out of the box on any computer with python and (e.g.) setuptools with complex XML templates using inheritence, then django won't help much at all. It will probably mostly get in your way. HTTP is not complicated. Try it! Seriously, try it! The next time you're writing a simple web app, read the headers and body of the request and construct your response by hand. You may never want to do it again, but it will never more be magic. Frameworks (sometimes) do a lot of stuff. Some of it (e.g. i18n) is pretty substantive. But its only useful if you need it and use it.

The problem, if you will, is that frameworks, and more so, the users and proponents of said frameworks, try to tell you what your problem is. Often, I've been told that the problem I'm trying to solve isn't a valid problem. Sometimes that assessment has been correct. Other times that assessment has been wrong. For instance, if the answer you're offered is "do it this way, its easier/better/more pythonic/etc", consider that. Is it the problem you want to solve? If you want a directed graph of bookmarks and someone tells you to use a hierarchy, is that what you want? Does it make it less useful to you? Does it not let you do things you care about?

I was in a dicsussion recently about whether e.g. "/new" or "/new/" was the "correct" canonical resource. The argument given was that "/new/ is easier to match with a regex dispatcher". This is how methodologies taint one's thought patterns. I wasn't using a regex dispatcher, so it really didn't matter to me. And the fact that the answer is tailored to a method -- a framework, if you will -- is to me a good example of bending what I'm trying to do (figure out which the canonical URL should be and how best do deal with the alternate case, redirect or 404) to a particular technological implementation, in this case one I wasn't even using.

That's how I feel about most arguments in http://jqueryvsmootools.com/ . For the record, I don't consider jQuery just a toolkit. It is a framework, with all of the good and bad that goes with it. Its not a complete JS framework: it is very DOM-centric. But its also not just a bunch of tools and integration layers to build your own damn whatever. It is a framework I happen to like and have found useful. But I'm not particularly trying to defend it, or for that matter cast any dispersions on MooTools. MooTools might be awesome! It solves a different problem, but could very well be cool. I just think the comparison is written in a way that turns me off to it since the author is obviously very involved in the MooTools community.

"MooTools is a framework that attempts to implement JavaScript as it should be (according to MooTools' authors)." - well, at least he's honest. What if I disagree? Are there consequences to this? I have things about any language I use that I don't like, but even if I was given carte blanche to change everything, others wouldn't necessarily like my changes.

"...while the jQuery version is more concise; its hover method accepts two methods - the first for mouse enter and the second for mouse leave. I personally like the fact that the MooTools code is more legible but that's a very subjective observation." - yes, and this is what I want 99% of the time for this problem. Its much easier for me to read, contrasting "I personally like the fact that the MooTools code is more legible but that's a very subjective observation."

"Again, the MooTools code is a bit more verbose, but also more explicit. Also note that the design pattern here is to store the reference to #faq in a variable, where jQuery uses its .end method to return to it." -- That is a design pattern and one I disagree with and don't use. jQuery doesn't force you to do this. And I don't. I store the variable like a sane person when jQuery "convenience" patterns don't fit. You can't (in general) match a regex with a regex (for example). Don't become so dogmatic about any tools you use so that you write bad code for aesthetic or design pattern sense. Design patterns are about communication. If you're adhering to design patterns that make you less communicative, stop.

jQuery doesn't modify native prototypes. Intentionally. I'm glad it doesn't.

"It's actually kind of rude to ask users to download two frameworks. The only reason to include two frameworks is because you want to use plug-ins from both, and in the minds of the MooTools authors (myself included), if you want a plug-in that isn't available with the framework of your choice, it's more appropriate for you to spend the time porting it to your environment than to ask your users to download another framework." - that's probably true. Note the word framework. The toolkit philosophy is somewhat different. A tool solves a specific problem. A toolkit (my definition) is loose integration layers on top of tools that work well together. The difference? While a framework tries to put your problem in its box, if jhammel's mathtool and joeuser's graphtool work well together, why not use them together?

So, really, no slight on MooTools. I will check it out and play with it someday. It probably solves a lot of interesting problems. And I will continue to use jQuery for the problems I know it solves well, which as the author correctly points out are not nor are meant to be all of the problems in JS-land. I do resent the framework >> toolkit attitude that he espouses. But that's my opinion, based on my practical experience. I can already think of arguments against my case and you're free to disagree