Bearfruit

Yeah, I have tried quite a few of the JS libraries/frameworks..for the best UI, I have to admit Ext has the edge of that, and for code simplicity..I vote jQuery. But for the best overall library, I would have to say Dojo. It has a good UI, (which is incredibly easy to use, with the HTML attributes, which I love and hate at the same time, because it breaks XHTML validity..which is pretty easy to solve..but thats a topic for another time). The thing I do like over Dojo is jQuerys selector system, Dojo is almost as good as jQuerys, but I like jQuerys more..and Dojo’s XHR wrapper could be a lot better, like jQuery’s AJAX wrapper. But I think the advantages outweight the few disadvantages, and I would have to say I like dojo the most, especially for any kind of larger project. And Dojo’s subscribe/publish system is amazing.

Hi matt,

Sorry, but how do you feel mootools community is elitist ? I am in the mootools IRC channel, and for sure we help a lot of people who come in there and I get help from others too. I did not feel it was elitist in any way.

Could you be more specific on why you felt mootools community was elitist ?

Regards

This is one of the lamest and stupidest things I have ever heard. I was thinking this would be some sort of technical overview and all the author did was showed his ignorance. You should get a job man.

I’ve spent a good amount of time in the #mootools irc channel too, insanekane. I’ve heard on many occasions people in the forums being mocked for asking “stupid” questions, esp about accordions. As a matter of fact, asking about accordions is almost guaranteed to get you mocked. Then there’s also a lot of “jQuery stinks…” type of chatter.

Enrique - sorry that wasn’t technical enough for you. I do have a job, and as a matter of fact my website is listed on the homepage of mootools.net. Here are some technical thoughts:

• It would be nice if mootools could be split into seperate files such as “core” and “effects” in order to cut down on the file size.
• Many of the popular toolkits are coming out with UI libraries based on the toolkit. This would be nice to have and if it were present I’d probably not even consider switching
• jQuery has closed the performance gap with mootools so that there is little difference between the two
• namespace clash - what happens if you have two toolkits that both want to define $()? It would be nice for moo to offer the ability to avoid this.

But really, it comes down to being on the winning team. I’ve seen too many technically superior projects die. It feels like moo is stagnating, focusing on very technical and abstract features. Meanwhile, jquery and others are working on shiny new stuff that makes the average scripter go “oooh… ahhh…”

Don’t get me wrong,

• I’m not ditching moo yet, I’m just looking around to see what else is out there. However, I’m starting to feel a little jealous of what some of the other toolkits are offering.
• Moo hasn’t regressed, everything that made me like it a year ago is still good
• Moo still feels like the smoothest and fastest library for effects, pretty much indistinguishable from flash for basic animation/tweening

Could someone help, I need the Fx.Elements of mootools implemented on my jQuery app, I could make this one from scratch but I dont quite have the time to make it, so I wanna ask if someone have seen a plugin or somethng like it around.

the site btw is
http://demos.mootools.net/Fx.Elements

Thanks in advance.

MooTools forums does seem very elitist, and extremely unfriendly. It’s almost a barrier to entry, as people get mocked for asking simple questions (and even when the answer is “it’s in the docs” or “we need to see code” they instead mock those asking questions and the topic’s closed - forcing a lot of converts away).

An improvement would be a reassessment, a simple first time notice that “please look in the docs/google it before asking” - a lot of people don’t do it. A lot of people don’t know what they’re searching for, or even quite what the “real” question is. I understand that you don’t want to hold someone’s hand, but just because the main devs are on the site, doesn’t mean that other fans can’t assist the “dumb users” or “noobs” on the site.

I’m trying to branch back into jQuery - while still using mootools for the majority of my implementations, I recognize the need to be proficient in more than one framework when you work with clients who may all ready be utilizing existing frameworks, creating a barrier for those who focus on their “framework of choice.”

Yo Matt (and all you others):

You should check out the new iframe and Swiff classes in Mootools. Iframe tunneling and manipulation rocks and the Swiff class makes JS to flash translation a snap!

I looked at jQuery and it appears that Moo has all the same selectors except Moo compounds them into one method while jQuery singles them out like this:

Mootools ‘.inject’ has 4 options myElement.inject(el[, where]); you would put top, bottom, after, before in the ‘where’ place and that same method would do all 4.

with jQuery you have to memorize a bunch of individual methods like this:

$(“p”).insertAfter(“#foo”);

$(“p”).insertBefore(“#foo”);

$(“span”).appendTo(“#foo”);

$(“p”).prepend(“Hello ”)

Why is it more clear to have 40 million little selectors separated and callable through a slew of different method arrangements when you could use simple text strings to indicate all of them in the same format and method. That seems counter intuitive and quite long-handed in my view.

You are right wrt the vibrations in the forums; the Olmo affair was pretty ugly (arrrhg, poor chap; couldn’t he get at least some loyalty from his own team?), and I remember an exemplary forum post where our beloved ‘the moo guy’ explained to a noob in no uncertain terms that he was “not welcome here”, merely because he posted a question in the wrong sub-section.

Cholerics aside, mootools is clean and elegant and very well thought out. I do have some personal issues with it, though, for instance, it seems very DOM element centric (especially with the new DOM storage), thus we had to come up with a different solutuion to the same problem. However, the Moo way is certainly valid.

We have solved the UI library problem by writing our own comprehensive UI on top of Mootools, so we are going to stick with it for some time to come.

The release cycle is too slow. We are waiting for 1.2 since like, forever, and have even implemented a lot of stuff that is promised for the new version on our own, since we want to work with stable versions. It does not help that the blog is updated only every other month or so, and it is hard to get a sense of progress even when monitoring the Trac.

The most serious problem for me is the lack of tools, though. We are using Aptana, and NaturalDocs is not parsed for code completion. Also, Mootools’ class system does not go well with the outline view.
If the moo people could get one of their ranks to write tools, then this would be a major reason to stay on board.