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 >> >> >
