Here's the reply I sent along to Rick: 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.
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. 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 potentially 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. It's not a certainty that we'll do this, but rather something that the dev team is actively discussing. I still believe that altering natives is the *ideal* for using a framework. It makes for elegant, easy to use code. However, there are times where I've had to port out features of MooTools into stand alone methods so that I can use them in places where I can't do that (bookmarklets for example). There are critics of MooTools who view extending natives as a bad practice, and they have numerous alternatives to use (Dojo being the framework I recommend in that case). If we make this extension optional in the future, it just makes the framework more versatile for those situations. On Tue, Jun 14, 2011 at 1:22 AM, אריה גלזר <[email protected]> wrote: > Great discussion! > My 2 cents - I'm having trouble seeing how one library can work with and > without altering the prototype without creating 2 separate code bases - at > the very least - you will have 2 separate and distinct plugin families that > won't be working together. > > how can a code base that does string.parseQueryString sit together with > $("text").parseQueryString() ? one might write a script that replaces one > code base to another, but in 90% of the cases, one can write a converter > from JQ to mootools (and the opposite) without too much hassle (as long as > there's a port for Class). I really don't see the point. > > If all you're talking about is specifically the Element prototype - I > assume it's less problematic since you don't directly access DOM elements > with mootools - you use Element or document.id or $$, which all allow you > to provide a wrapper just as well as modify the prototype (which is exactly > why you could use mootools on IE<8) but that would introduce a large > performance penalty for the collections. As I understand it - this is a > place where mootools paradigm is clearly faster than any wrapper based > solution out there. > > The only place we encounter real trouble with Mootools paradigm is when we > try to port code to the Node environment. I know there's a script for this, > but it breaks the potential of using the same code at both the server and > the client. > > I thought I'll add this great talk from the latest JSConf- > > http://blip.tv/jsconf/jsconf2011-andrew-dupont-everything-is-permitted-extending-built-ins-5211542 > > One of the main pointers I take from it (among many others - this is an > amazing talk) is that as long as you use exactly one such tool in your code > it is quite fine and legitimate. It obviously adds limits to what you might > use alongside it, but that's the case anyway. > > > > > On Tue, Jun 14, 2011 at 10:18 AM, mrrick <[email protected]> wrote: > >> 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 >> >> >> > > > -- > Arieh Glazer > אריה גלזר > 052-5348-561 > http://www.arieh.co.il > http://www.link-wd.co.il > >
