This is only a fix for Element. There's also an open discussion of possibly not extending any native prototypes. I'm not in any way espousing the likelihood of us adding such a change to the framework, only saying that we have and continue to discuss it.
On Tue, Jun 14, 2011 at 12:45 PM, Arian Stolwijk <[email protected]> wrote: > jfyi > > >> The one feature you are referring to - changing MooTools Core so that it >> no longer updates native prototypes - has not yet been implemented, > > > it is, it's just not ready yet :) See > https://github.com/mootools/mootools-core/blob/2.0wip/Source/Element/Element.js > and https://github.com/mootools/mootools-core/pull/78 > > > > On Tue, Jun 14, 2011 at 8:58 PM, Aaron Newton <[email protected]> wrote: > >> 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 >>> >>> >> >
