Greetings. I contacted Aaron Newton - developer of mootools with a few
questions about DOM direct prototype extensions and the state of
release. I also received some other insightful information about it's
recent past and future goals, reaction to a concern over prototype
extension as well as hints regarding possibly making prototype
extensions an option. I like that idea quite a bit, a little like
having the cake and eating it too. I invite you to read below this
information graciously provided by Mr. Newton.
BTW My name is Rick and I may be lurking in the background to get to
know this group.
Aaron, I hope this makes up for "tricking" you into that response :).
I really did have the intention of taking the questions here for
everyone, especially noobies to the framework like myself.
Best regards,
Rick
"
On 6/14/2011 1:00 AM, Aaron Newton wrote:
>
> (me) I hope you let me join the group, maybe I'll have something to
> contribute...in time of course.
>
>
>(AN) Let me know if you didn't get in.
>
>
>(me) There is another article I have yet to finish that came out on Nov. 1
>2008 from Microsoft that appears to be implying that they are specifically
>adding better support for DOM extension to empower JS developers. So far I am
>infering that they are suggesting this is a valid technique and seem to
>condone it. Here's an exerpt from the into to the document: "To further
>empower Web developers with the programming tools necessary to build new
>JavaScript scenarios that innovate, extend, and build-upon the Web platform,
>Internet Explorer 8 offers a collection of features that extend some of
>JavaScript's advanced functionality into the Document Object Model (DOM). This
>article provides an overview of JavaScript prototype inheritance and
>introduces the DOM prototypes feature available in Internet Explorer 8; Part 2
>introduces a new type of JavaScript property called an accessor property (or
>getter/setter property)." I can send you the link but I didn't want this
>reply to be filtered into your junk folder for having a link. If I feel the
>thread could benefit I may post a reference to it with any questions I may
>have that have not been addressed.
>
>
>(AN) What they're saying there is that starting in IE8 you can alter the
>Element prototype, something that you can't do in IE6/7. For MooTools to work
>in those browsers, it has to assign the extensions manually to every element
>it touches, which adds a moderate overhead to the library in those browsers.
>In other words, IE6 and 7 see a performance hit when MooTools touches an
>element. IE8 allows us to alter the prototype and therefor doesn't have this
>performance penalty.
>
>
>(me) Two other questions, just off the top of my head I may ask, may be 1)
>in April 2010 you mentioned mootools 2.0 might have some changes addressing
>the concerns (from the article about DOM direct extension. This leaves me
>wondering if there is a target date for such a release and 2) Would existing
>code (based on the 1.3 release) need significant updating or would 2.0 be
>backwards compatible.
>
>
>(AN) It is our goal for every release to be as close to 100% backwards
>compatible with the last. With the 2.0 release this may not be the case, as
>it's a major version update, but it's still our goal to provide a pathway to
>help developers upgrade. To put it another way, if we can make it compatible,
>we will.
>
>(AN) MooTools 2.0 was a branch of code a year ago that had many new features.
>It was, in many ways, a large rewrite from scratch of the framework. After
>many, many months of work with no release in sight, we started back-porting
>most of those features and releasing them as iterative changes. Thus MooTools
>1.2.5 had changes to Class and other internals. MooTools 1.3 removed all the
>$methods ($A became Array.from, $lambda became Function.from, etc). Most of
>the work done up to that point is now released.
>
>(AN) The one feature you are referring to - changing MooTools Core so that it
>no longer updates native prototypes - has not yet been implemented, though it
>is still on our road map. The alterations to the native prototype will be
>available as an option you can enable. So developers who want these extensions
>(as it allows you to write more elegant code) can use them, and those who do
>not are not forced to. This also has the added benefit of offering us
>compatibility.
>
>
> (me) I also wonder if using wrappers rather then direct extension would
> adversely affect mootools' beautiful animations? When I saw the JQuery
> accordion I was not really all that impressed, it was all jerky and nowhere
> near as smooth as the mootools demos I've seen. The syntax and choice of
> words for funtions and what not, basically the mootools code makes more
> sense. For example addEvent makes a hell of alot more sense, and describes
> what the method is doing, much better then bind. I mean bind what?
> addEvent, oh, we must be adding an event, great. Anyway, I think I will
> learn mootools.
>
>
>(AN) It won't affect performance, though it will make the file-size of the
>library larger.
>
>
> (me {sheepish}) Please don't feel obligated to respond, I've already taken
> more of your time then I should, thanks for that. You can if you are
> inclined but if I have questions I'll research and post if I can't find
> answers anywhere else.
>
>
>(AN {being funny...I think}) Actually, you tricked me. I wanted you to ask
>these questions on the mailing list so my replies would be helpful to others.
>I got home just now and started typing and here I've written all this stuff
>and it's not on the mailing list... I have no one to blame but myself."
(AN) If you haven't seen it, this may be useful to you:
http://mootoolsvsjquery.com
(Me from here down.)
I'd also like to add this link. I've been furiously trying to
evaluate the difference between mootools and Jquery, why is Jquery so
popular but I really see Mootools more for me? Anyway my conclusions
mirror the thoughts expressed in this article almost to a tee.
http://juliocapote.com/post/52467447/why-mootools-or-why-not-jquery
Do you prefer,
".bind( eventType, [ eventData ], handler(eventObject) )"
"handler(eventObject)" is the function by the way, and ".bind" means
addEvent.
or
"$('elementId').addEvent('click', function() { //or
a named function.
...do this...
});"
Huge over simplification but it really does kind of boil down to that
in a way. Add to that its more object oriented nature and silky
smooth animations and it just "speaks" to me more.
I would like to be helpful by pointing this out too:
Did you know the library was linked to resources/"assets" on the CNET
servers? Well apparently they are and this is what you are advised to
do - http://www.clientcide.com/wiki/cnet-libraries/00a-assets
Really, isn't that what you want anyway?
Now if your still reading you have one heck of a constitution but here
is even more!
Did you know Aaron Newton wrote the book on mootools? Literally, he
did. I've found it on Amazon and Chapters. It is called "MooTools
Essentials: The Official MooTools Reference for JavaScript and Ajax
Development" I'm garbing my copy -
http://www.amazon.com/Mootools-Essentials-Reference-JavaScript-Firstpress/dp/1430209836/ref=sr_1_3?ie=UTF8&qid=1308033127&sr=8-3
I mean come on! When was the last time you bought a technology book
for $20. It's more affordable this one is the real McCoy! Look into
it...
Okay, okay that's enough now...BUT WAIT! THERE'S MORE!!!
http://www.clientcide.com/js/#!
http://cheeaun.github.com/mooeditable/
Like what you see so far well take what you find here -
http://mootools.net/demos/
and have some fun with it over here - http://jsfiddle.net/cheeaun/NHBVa/
This probably should be up higher up but here is a good place to start
should you require an overview before diving in -
http://walkthrough.ifupdown.com/walkthrough-1.2/start - it's a couple
years old but gives you some good basics.
Regards,
Rick
