[Moo] anyone want to have a go in converting this jquery performance article into mootools one?
|
|
Dimitar Christoff
|
http://www.artzstudio.com/2009/04/jquery-performance-rules/ I think most of it is really obvious and applies to mootools to a large degree - perhaps we can do our own best practices for effecient mootools code? in doing so we can also focus on particulars of our selectors system, coding to the pattern and inheritance, extending native classes when possible etc etc. in any case, not a bad read this. for example, I had not considered the event bubbling performance implications - see 7. Leverage Event Delegation (a.k.a. Bubbling) we could do it on wave or gdocs or something... ? Regards, -- Dimitar Christoff <[hidden email]> - http://fragged.org/ |
||||||||||||||||
anutron
|
it's funny, almost all those suggestions can be summed up roughly as, "...or use mootools, which encourages you to program this way to begin with."
On Sun, Oct 25, 2009 at 4:14 PM, Dimitar Christoff <[hidden email]> wrote:
The MooTools Tutorial: www.mootorial.com
Clientcide: www.clientcide.com
|
||||||||||||||||
Ryan Florence
|
Some javascript/style in this post has been disabled (why?)
Ha, that's what I was thinking. Sent from my iPhone
|
||||||||||||||||
nwhite-2
|
In reply to this post
by anutron
Some javascript/style in this post has been disabled (why?)
I would argue that #4 isn't a speed advantage and in some cases harmful. I think some of the suggestions on selectors are valid and have been violated by mootools code in the wild. ( helpful tips) The suggestions about Dom insertion are also good. Again, general good practice that applies to all Dom js. Again I've seen mootools code violate this principle. One practice "encouraged" by mootools that I don't always agree with is the use of .each(). Calling a function for each iteration isn't the greatest thing especially when fast tight loops are needed. The article also points out the use of window.addEvent('load') instead of window.addEvent('domready'). As a community I don't think we point out the differences enough. We too have a tendency of overselling 'domready'. Event Delegation is a really good thing. It's sad that mootools doesn't have this in the core. I'm guilty of not utilizing this awesome technique as much as I could. I think the community could benefit greatly from more awareness in this department. The points in the article about using references doesn't really apply to mootools if you follow the 'moo way'. Using classes gives this one to you for free.
|
||||||||||||||||
keif
|
After reading it, this seems more like a "Improve Your JavaScript" versus really a jQuery specific article. I've been drafting a post over the general topic, I wouldn't mind plugging MooTools in it (especially Aaron's comment: "...or use mootools, which encourages you to program this way to begin with." -kb On Oct 26, 1:50 am, Nathan White <[hidden email]> wrote: > I would argue that #4 isn't a speed advantage and in some cases harmful. > > I think some of the suggestions on selectors are valid and have been > violated by mootools code in the wild. ( helpful tips) > > The suggestions about Dom insertion are also good. Again, general good > practice that applies to all Dom js. Again I've seen mootools code > violate this principle. > > One practice "encouraged" by mootools that I don't always agree with > is the use of .each(). Calling a function for each iteration isn't the > greatest thing especially when fast tight loops are needed. > > The article also points out the use of window.addEvent('load') instead > of window.addEvent('domready'). As a community I don't think we point > out the differences enough. We too have a tendency of overselling > 'domready'. > > Event Delegation is a really good thing. It's sad that mootools > doesn't have this in the core. I'm guilty of not utilizing this > awesome technique as much as I could. I think the community could > benefit greatly from more awareness in this department. > > The points in the article about using references doesn't really apply > to mootools if you follow the 'moo way'. Using classes gives this one > to you for free. > > On Oct 25, 2009, at 9:01 PM, Aaron Newton <[hidden email]> wrote: > > > it's funny, almost all those suggestions can be summed up roughly > > as, "...or use mootools, which encourages you to program this way to > > begin with." > > > On Sun, Oct 25, 2009 at 4:14 PM, Dimitar Christoff <[hidden email] > > > wrote: > > >http://www.artzstudio.com/2009/04/jquery-performance-rules/ > > > I think most of it is really obvious and applies to mootools to a > > large > > degree - perhaps we can do our own best practices for effecient > > mootools > > code? in doing so we can also focus on particulars of our selectors > > system, coding to the pattern and inheritance, extending native > > classes > > when possible etc etc. > > > in any case, not a bad read this. for example, I had not considered > > the > > event bubbling performance implications - see 7. Leverage Event > > Delegation (a.k.a. Bubbling) > > > we could do it on wave or gdocs or something... ? > > > Regards, > > -- > > Dimitar Christoff <[hidden email]> -http://fragged.org/ |
||||||||||||||||
|
anutron
|
my comment was a little facetious. it's quite easy to do most of those bad practices in mootools. if you're using classes, you probably won't do half of them without even trying. knowing when and how to write classes, and when and how to break things up into mixins and sub-classes and when to alter native prototypes are the types of things many mootools users don't understand.
On Thu, Oct 29, 2009 at 2:20 AM, keif <[hidden email]> wrote:
The MooTools Tutorial: www.mootorial.com
Clientcide: www.clientcide.com
|
||||||||||||||||
|
keif
|
Aaron, I kind of took it as that - honestly my first reaction was "geeze, that's a little harsh" until I thought about what you said a bit more. I took it to mean - MooTools (and really, the community in general) encourages you to adhere to the "better" practices in your coding, period. It's not facetious, it's really an embodiment of the quality of code I tend to see from MooTools developers (and I'm being broad in that description, including random MooTools developers online that aren't in the group). I had this conversation with a friend the other day, very honestly I was complaining about a contractor's jQuery code, which utilized a jQuery plugin they found. It was atrocious, and I made the comment about how I hated how the code was laid out (variables were all letters, no clearly defined structure, so it was more like they attempted to obfuscate it so if you needed to debug it you needed to reverse engineer the entire thing). We came to the conclusion that the problem *isn't* with jQuery, it's with jQuery plug-in authors. Whereas with MooTools, we write classes. OOP principles really seem prevalent. jQuery plug-ins? They seem to be a "roll your own, no set standard, have fun." Of course, the stuff said here could be expounded upon, clarified, and caveats and all that as well, I don't mean to say "all jquery plugins suck" or "all contractors suck" I'm saying - *in my experience* I've seen so much better, elegant, sexy code come from developers that code MooTools, and so much more shit code from people (notice, I said people, not developers) that code jquery. -kb On Oct 29, 11:26 am, Aaron Newton <[hidden email]> wrote: > my comment was a little facetious. it's quite easy to do most of those bad > practices in mootools. if you're using classes, you probably won't do half > of them without even trying. knowing when and how to write classes, and when > and how to break things up into mixins and sub-classes and when to alter > native prototypes are the types of things many mootools users don't > understand. > > On Thu, Oct 29, 2009 at 2:20 AM, keif <[hidden email]> wrote: > > > After reading it, this seems more like a "Improve Your JavaScript" > > versus really a jQuery specific article. I've been drafting a post > > over the general topic, I wouldn't mind plugging MooTools in it > > (especially Aaron's comment: "...or use mootools, which encourages you > > to program this way to begin with." > > > -kb > > > On Oct 26, 1:50 am, Nathan White <[hidden email]> wrote: > > > I would argue that #4 isn't a speed advantage and in some cases harmful. > > > > I think some of the suggestions on selectors are valid and have been > > > violated by mootools code in the wild. ( helpful tips) > > > > The suggestions about Dom insertion are also good. Again, general good > > > practice that applies to all Dom js. Again I've seen mootools code > > > violate this principle. > > > > One practice "encouraged" by mootools that I don't always agree with > > > is the use of .each(). Calling a function for each iteration isn't the > > > greatest thing especially when fast tight loops are needed. > > > > The article also points out the use of window.addEvent('load') instead > > > of window.addEvent('domready'). As a community I don't think we point > > > out the differences enough. We too have a tendency of overselling > > > 'domready'. > > > > Event Delegation is a really good thing. It's sad that mootools > > > doesn't have this in the core. I'm guilty of not utilizing this > > > awesome technique as much as I could. I think the community could > > > benefit greatly from more awareness in this department. > > > > The points in the article about using references doesn't really apply > > > to mootools if you follow the 'moo way'. Using classes gives this one > > > to you for free. > > > > On Oct 25, 2009, at 9:01 PM, Aaron Newton <[hidden email]> wrote: > > > > > it's funny, almost all those suggestions can be summed up roughly > > > > as, "...or use mootools, which encourages you to program this way to > > > > begin with." > > > > > On Sun, Oct 25, 2009 at 4:14 PM, Dimitar Christoff < > > [hidden email] > > > > > wrote: > > > > >http://www.artzstudio.com/2009/04/jquery-performance-rules/ > > > > > I think most of it is really obvious and applies to mootools to a > > > > large > > > > degree - perhaps we can do our own best practices for effecient > > > > mootools > > > > code? in doing so we can also focus on particulars of our selectors > > > > system, coding to the pattern and inheritance, extending native > > > > classes > > > > when possible etc etc. > > > > > in any case, not a bad read this. for example, I had not considered > > > > the > > > > event bubbling performance implications - see 7. Leverage Event > > > > Delegation (a.k.a. Bubbling) > > > > > we could do it on wave or gdocs or something... ? > > > > > Regards, > > > > -- > > > > Dimitar Christoff <[hidden email]> -http://fragged.org/ |
||||||||||||||||
Barry van Oudtshoorn
|
Leif, I think that it might also be that whereas jQuery enjoys a very large degree of use in smaller, personal projects, from what I've seen, MooTools is predominantly used in professional environments. What this means, then, is that you get a lot of 'amateur' code in jQuery projects because, well, it's used by amateurs a lot. :) That being said, I do completely agree that writing javascript with MooTools encourages clear, well-structured code. Sent from my mobile device On 1 Nov 2009, at 10:12, keif <[hidden email]> wrote: > > Aaron, I kind of took it as that - honestly my first reaction was > "geeze, that's a little harsh" until I thought about what you said a > bit more. > > I took it to mean - MooTools (and really, the community in general) > encourages you to adhere to the "better" practices in your coding, > period. It's not facetious, it's really an embodiment of the quality > of code I tend to see from MooTools developers (and I'm being broad in > that description, including random MooTools developers online that > aren't in the group). > > I had this conversation with a friend the other day, very honestly I > was complaining about a contractor's jQuery code, which utilized a > jQuery plugin they found. It was atrocious, and I made the comment > about how I hated how the code was laid out (variables were all > letters, no clearly defined structure, so it was more like they > attempted to obfuscate it so if you needed to debug it you needed to > reverse engineer the entire thing). > > We came to the conclusion that the problem *isn't* with jQuery, it's > with jQuery plug-in authors. Whereas with MooTools, we write classes. > OOP principles really seem prevalent. jQuery plug-ins? They seem to be > a "roll your own, no set standard, have fun." > > Of course, the stuff said here could be expounded upon, clarified, and > caveats and all that as well, I don't mean to say "all jquery plugins > suck" or "all contractors suck" I'm saying - *in my experience* I've > seen so much better, elegant, sexy code come from developers that code > MooTools, and so much more shit code from people (notice, I said > people, not developers) that code jquery. > > -kb > > On Oct 29, 11:26 am, Aaron Newton <[hidden email]> wrote: >> my comment was a little facetious. it's quite easy to do most of >> those bad >> practices in mootools. if you're using classes, you probably won't >> do half >> of them without even trying. knowing when and how to write classes, >> and when >> and how to break things up into mixins and sub-classes and when to >> alter >> native prototypes are the types of things many mootools users don't >> understand. >> >> On Thu, Oct 29, 2009 at 2:20 AM, keif <[hidden email]> wrote: >> >>> After reading it, this seems more like a "Improve Your JavaScript" >>> versus really a jQuery specific article. I've been drafting a post >>> over the general topic, I wouldn't mind plugging MooTools in it >>> (especially Aaron's comment: "...or use mootools, which encourages >>> you >>> to program this way to begin with." >> >>> -kb >> >>> On Oct 26, 1:50 am, Nathan White <[hidden email]> wrote: >>>> I would argue that #4 isn't a speed advantage and in some cases >>>> harmful. >> >>>> I think some of the suggestions on selectors are valid and have >>>> been >>>> violated by mootools code in the wild. ( helpful tips) >> >>>> The suggestions about Dom insertion are also good. Again, general >>>> good >>>> practice that applies to all Dom js. Again I've seen mootools code >>>> violate this principle. >> >>>> One practice "encouraged" by mootools that I don't always agree >>>> with >>>> is the use of .each(). Calling a function for each iteration >>>> isn't the >>>> greatest thing especially when fast tight loops are needed. >> >>>> The article also points out the use of window.addEvent('load') >>>> instead >>>> of window.addEvent('domready'). As a community I don't think we >>>> point >>>> out the differences enough. We too have a tendency of overselling >>>> 'domready'. >> >>>> Event Delegation is a really good thing. It's sad that mootools >>>> doesn't have this in the core. I'm guilty of not utilizing this >>>> awesome technique as much as I could. I think the community could >>>> benefit greatly from more awareness in this department. >> >>>> The points in the article about using references doesn't really >>>> apply >>>> to mootools if you follow the 'moo way'. Using classes gives this >>>> one >>>> to you for free. >> >>>> On Oct 25, 2009, at 9:01 PM, Aaron Newton <[hidden email]> wrote: >> >>>>> it's funny, almost all those suggestions can be summed up roughly >>>>> as, "...or use mootools, which encourages you to program this >>>>> way to >>>>> begin with." >> >>>>> On Sun, Oct 25, 2009 at 4:14 PM, Dimitar Christoff < >>> [hidden email] >>>>>> wrote: >> >>>>> http://www.artzstudio.com/2009/04/jquery-performance-rules/ >> >>>>> I think most of it is really obvious and applies to mootools to a >>>>> large >>>>> degree - perhaps we can do our own best practices for effecient >>>>> mootools >>>>> code? in doing so we can also focus on particulars of our >>>>> selectors >>>>> system, coding to the pattern and inheritance, extending native >>>>> classes >>>>> when possible etc etc. >> >>>>> in any case, not a bad read this. for example, I had not >>>>> considered >>>>> the >>>>> event bubbling performance implications - see 7. Leverage Event >>>>> Delegation (a.k.a. Bubbling) >> >>>>> we could do it on wave or gdocs or something... ? >> >>>>> Regards, >>>>> -- >>>>> Dimitar Christoff <[hidden email]> -http://fragged.org/ |
||||||||||||||||
Daniel Lohse
|
In reply to this post
by keif
Hey Keif, I agree with you - in general. But I'd like to point out something else: for the really advanced topics I almost always have to go read some code by other developers. I've been coding for a major television network here in Germany for their Vancouver 2010 online presence and sometimes... well, it wasn't pretty. I knew that I could've used events but didn't *really* knew it. So sometimes, my code got a little 'lost', not as clean as I wanted it to. It's easy to lose track when you're dealing with a 1000 lines of MooTools classes (more than 15 classes). But these advanced topics and the fact that you're actually reading other people's code is, to my mind, critical when wanting to learn clean code and great code structure. Knowing when to use subclass and when to just implement some other class is really, really important. I'm in the middle of negotiating to open-source these classes and then, hopefully, someone can look at the code and make it pretty again. ;-) But I'm more than glad that I could prevent them from using jQuery so the network can hopefully be convinced to use MooTools everywhere. :) Cheers, Daniel On 2009-11-01, at 1/November, 3:12 AM, keif wrote: > > Aaron, I kind of took it as that - honestly my first reaction was > "geeze, that's a little harsh" until I thought about what you said a > bit more. > > I took it to mean - MooTools (and really, the community in general) > encourages you to adhere to the "better" practices in your coding, > period. It's not facetious, it's really an embodiment of the quality > of code I tend to see from MooTools developers (and I'm being broad in > that description, including random MooTools developers online that > aren't in the group). > > I had this conversation with a friend the other day, very honestly I > was complaining about a contractor's jQuery code, which utilized a > jQuery plugin they found. It was atrocious, and I made the comment > about how I hated how the code was laid out (variables were all > letters, no clearly defined structure, so it was more like they > attempted to obfuscate it so if you needed to debug it you needed to > reverse engineer the entire thing). > > We came to the conclusion that the problem *isn't* with jQuery, it's > with jQuery plug-in authors. Whereas with MooTools, we write classes. > OOP principles really seem prevalent. jQuery plug-ins? They seem to be > a "roll your own, no set standard, have fun." > > Of course, the stuff said here could be expounded upon, clarified, and > caveats and all that as well, I don't mean to say "all jquery plugins > suck" or "all contractors suck" I'm saying - *in my experience* I've > seen so much better, elegant, sexy code come from developers that code > MooTools, and so much more shit code from people (notice, I said > people, not developers) that code jquery. > > -kb > > On Oct 29, 11:26 am, Aaron Newton <[hidden email]> wrote: >> my comment was a little facetious. it's quite easy to do most of >> those bad >> practices in mootools. if you're using classes, you probably won't >> do half >> of them without even trying. knowing when and how to write classes, >> and when >> and how to break things up into mixins and sub-classes and when to >> alter >> native prototypes are the types of things many mootools users don't >> understand. >> >> On Thu, Oct 29, 2009 at 2:20 AM, keif <[hidden email]> wrote: >> >>> After reading it, this seems more like a "Improve Your JavaScript" >>> versus really a jQuery specific article. I've been drafting a post >>> over the general topic, I wouldn't mind plugging MooTools in it >>> (especially Aaron's comment: "...or use mootools, which encourages >>> you >>> to program this way to begin with." >> >>> -kb >> >>> On Oct 26, 1:50 am, Nathan White <[hidden email]> wrote: >>>> I would argue that #4 isn't a speed advantage and in some cases >>>> harmful. >> >>>> I think some of the suggestions on selectors are valid and have >>>> been >>>> violated by mootools code in the wild. ( helpful tips) >> >>>> The suggestions about Dom insertion are also good. Again, general >>>> good >>>> practice that applies to all Dom js. Again I've seen mootools code >>>> violate this principle. >> >>>> One practice "encouraged" by mootools that I don't always agree >>>> with >>>> is the use of .each(). Calling a function for each iteration >>>> isn't the >>>> greatest thing especially when fast tight loops are needed. >> >>>> The article also points out the use of window.addEvent('load') >>>> instead >>>> of window.addEvent('domready'). As a community I don't think we >>>> point >>>> out the differences enough. We too have a tendency of overselling >>>> 'domready'. >> >>>> Event Delegation is a really good thing. It's sad that mootools >>>> doesn't have this in the core. I'm guilty of not utilizing this >>>> awesome technique as much as I could. I think the community could >>>> benefit greatly from more awareness in this department. >> >>>> The points in the article about using references doesn't really >>>> apply >>>> to mootools if you follow the 'moo way'. Using classes gives this >>>> one >>>> to you for free. >> >>>> On Oct 25, 2009, at 9:01 PM, Aaron Newton <[hidden email]> wrote: >> >>>>> it's funny, almost all those suggestions can be summed up roughly >>>>> as, "...or use mootools, which encourages you to program this >>>>> way to >>>>> begin with." >> >>>>> On Sun, Oct 25, 2009 at 4:14 PM, Dimitar Christoff < >>> [hidden email] >>>>>> wrote: >> >>>>> http://www.artzstudio.com/2009/04/jquery-performance-rules/ >> >>>>> I think most of it is really obvious and applies to mootools to a >>>>> large >>>>> degree - perhaps we can do our own best practices for effecient >>>>> mootools >>>>> code? in doing so we can also focus on particulars of our >>>>> selectors >>>>> system, coding to the pattern and inheritance, extending native >>>>> classes >>>>> when possible etc etc. >> >>>>> in any case, not a bad read this. for example, I had not >>>>> considered >>>>> the >>>>> event bubbling performance implications - see 7. Leverage Event >>>>> Delegation (a.k.a. Bubbling) >> >>>>> we could do it on wave or gdocs or something... ? >> >>>>> Regards, >>>>> -- >>>>> Dimitar Christoff <[hidden email]> -http://fragged.org/ |
||||||||||||||||
|
Dimitar Christoff
|
In reply to this post
by keif
> I took it to mean - MooTools (and really, the community in general) > encourages you to adhere to the "better" practices in your coding, > period. It's not facetious I would disagree - it is kind of funny because it works in an odd way. The problem is, the so called community (the core / more team + usual suspects on the list and twitter) are quite subjective in one regard - it all looks very easy from the top but paving the way for new comers and relative new comers can be considered beyond what's called for. And yes, resources are available but it's a different matter if they "read" well to those that don't know what a dollar sign is yet or try to figure why our $ is not the same as jQuery's... Once you "get/grock mootools" you are able to extract far more meaningful help and advice and can appreciate and understand what the others do. So these practices we speak of, you start to spot them, then to question them and look them up. But often, there is no real explanation available in the code/comments or on the list. For example, understanding namespacing but also understanding the impact on overall performance, on noconflict mode and the extent to which a mootools based prototypical script can play nice - it's a bit much to get right from the source code of a snippet by davidwalsh.name :D I guess all I am saying is, not everything is obvious to those that start from the ground up. What and how you code as a part of your subconscious (or nott) routine often will not come easy to others... So why not put a guide of sorts of the latest and best trends in js / mootools / performance and how they can be applied to our code? This is the one thing we lack over jquery - better support and a broader entry funnel imo, but there should be resources / guidelines for the top-end too... Kind regards, -- Dimitar Christoff <[hidden email]> - http://fragged.org/ |
||||||||||||||||
|
keif
|
In reply to this post
by Barry van Oudtshoorn
Barry, I'm going to have to disagree with you (without doing a lot of fact checking, so I could be wrong). I work for an interactive marketing agency, and jQuery is getting used a lot (primarilly at Client's demand). MooTools still is my primary toolkit of choice, but jQuery and Dojo both are used for large ecommerce sites I've worked on. That being said, the "amateur hour" from jQuery comes across via *some* plugin authors, but unfortunately I'm seeing people run with the plugins as a "solution" vs. "I like what they did, now let's make it better" - but the downside is I've seen great jquery plug-ins obfuscated all to hell (why!?) and also seen guys how great promise by fully admitting they're new to writing jQuery plug-ins, so "it could be better." But that's a whole other debate that could last for awhile :-) -kb On Nov 1, 1:35 am, Barry van Oudtshoorn <[hidden email]> wrote: > Leif, I think that it might also be that whereas jQuery enjoys a very > large degree of use in smaller, personal projects, from what I've > seen, MooTools is predominantly used in professional environments. > What this means, then, is that you get a lot of 'amateur' code in > jQuery projects because, well, it's used by amateurs a lot. :) > > That being said, I do completely agree that writing javascript with > MooTools encourages clear, well-structured code. > > Sent from my mobile device > > On 1 Nov 2009, at 10:12, keif <[hidden email]> wrote: > > > > > Aaron, I kind of took it as that - honestly my first reaction was > > "geeze, that's a little harsh" until I thought about what you said a > > bit more. > > > I took it to mean - MooTools (and really, the community in general) > > encourages you to adhere to the "better" practices in your coding, > > period. It's not facetious, it's really an embodiment of the quality > > of code I tend to see from MooTools developers (and I'm being broad in > > that description, including random MooTools developers online that > > aren't in the group). > > > I had this conversation with a friend the other day, very honestly I > > was complaining about a contractor's jQuery code, which utilized a > > jQuery plugin they found. It was atrocious, and I made the comment > > about how I hated how the code was laid out (variables were all > > letters, no clearly defined structure, so it was more like they > > attempted to obfuscate it so if you needed to debug it you needed to > > reverse engineer the entire thing). > > > We came to the conclusion that the problem *isn't* with jQuery, it's > > with jQuery plug-in authors. Whereas with MooTools, we write classes. > > OOP principles really seem prevalent. jQuery plug-ins? They seem to be > > a "roll your own, no set standard, have fun." > > > Of course, the stuff said here could be expounded upon, clarified, and > > caveats and all that as well, I don't mean to say "all jquery plugins > > suck" or "all contractors suck" I'm saying - *in my experience* I've > > seen so much better, elegant, sexy code come from developers that code > > MooTools, and so much more shit code from people (notice, I said > > people, not developers) that code jquery. > > > -kb > > > On Oct 29, 11:26 am, Aaron Newton <[hidden email]> wrote: > >> my comment was a little facetious. it's quite easy to do most of > >> those bad > >> practices in mootools. if you're using classes, you probably won't > >> do half > >> of them without even trying. knowing when and how to write classes, > >> and when > >> and how to break things up into mixins and sub-classes and when to > >> alter > >> native prototypes are the types of things many mootools users don't > >> understand. > > >> On Thu, Oct 29, 2009 at 2:20 AM, keif <[hidden email]> wrote: > > >>> After reading it, this seems more like a "Improve Your JavaScript" > >>> versus really a jQuery specific article. I've been drafting a post > >>> over the general topic, I wouldn't mind plugging MooTools in it > >>> (especially Aaron's comment: "...or use mootools, which encourages > >>> you > >>> to program this way to begin with." > > >>> -kb > > >>> On Oct 26, 1:50 am, Nathan White <[hidden email]> wrote: > >>>> I would argue that #4 isn't a speed advantage and in some cases > >>>> harmful. > > >>>> I think some of the suggestions on selectors are valid and have > >>>> been > >>>> violated by mootools code in the wild. ( helpful tips) > > >>>> The suggestions about Dom insertion are also good. Again, general > >>>> good > >>>> practice that applies to all Dom js. Again I've seen mootools code > >>>> violate this principle. > > >>>> One practice "encouraged" by mootools that I don't always agree > >>>> with > >>>> is the use of .each(). Calling a function for each iteration > >>>> isn't the > >>>> greatest thing especially when fast tight loops are needed. > > >>>> The article also points out the use of window.addEvent('load') > >>>> instead > >>>> of window.addEvent('domready'). As a community I don't think we > >>>> point > >>>> out the differences enough. We too have a tendency of overselling > >>>> 'domready'. > > >>>> Event Delegation is a really good thing. It's sad that mootools > >>>> doesn't have this in the core. I'm guilty of not utilizing this > >>>> awesome technique as much as I could. I think the community could > >>>> benefit greatly from more awareness in this department. > > >>>> The points in the article about using references doesn't really > >>>> apply > >>>> to mootools if you follow the 'moo way'. Using classes gives this > >>>> one > >>>> to you for free. > > >>>> On Oct 25, 2009, at 9:01 PM, Aaron Newton <[hidden email]> wrote: > > >>>>> it's funny, almost all those suggestions can be summed up roughly > >>>>> as, "...or use mootools, which encourages you to program this > >>>>> way to > >>>>> begin with." > > >>>>> On Sun, Oct 25, 2009 at 4:14 PM, Dimitar Christoff < > >>> [hidden email] > >>>>>> wrote: > > >>>>>http://www.artzstudio.com/2009/04/jquery-performance-rules/ > > >>>>> I think most of it is really obvious and applies to mootools to a > >>>>> large > >>>>> degree - perhaps we can do our own best practices for effecient > >>>>> mootools > >>>>> code? in doing so we can also focus on particulars of our > >>>>> selectors > >>>>> system, coding to the pattern and inheritance, extending native > >>>>> classes > >>>>> when possible etc etc. > > >>>>> in any case, not a bad read this. for example, I had not > >>>>> considered > >>>>> the > >>>>> event bubbling performance implications - see 7. Leverage Event > >>>>> Delegation (a.k.a. Bubbling) > > >>>>> we could do it on wave or gdocs or something... ? > > >>>>> Regards, > >>>>> -- > >>>>> Dimitar Christoff <[hidden email]> -http://fragged.org/ |
||||||||||||||||
|
keif
|
In reply to this post
by Daniel Lohse
Daniel, I'm totally with you - when your coding at the enterprise level (and time and money are more of a factor than making sure your code is clean and easy to pass to someone else) your code can get ugly. I think a lot of developers have been in your shoes and know your pain! (Myself included). -kb On Nov 1, 6:47 am, Daniel Lohse <[hidden email]> wrote: > Hey Keif, > > I agree with you - in general. But I'd like to point out something > else: for the really advanced topics I almost always have to go read > some code by other developers. I've been coding for a major television > network here in Germany for their Vancouver 2010 online presence and > sometimes... well, it wasn't pretty. I knew that I could've used > events but didn't *really* knew it. So sometimes, my code got a little > 'lost', not as clean as I wanted it to. It's easy to lose track when > you're dealing with a 1000 lines of MooTools classes (more than 15 > classes). But these advanced topics and the fact that you're actually > reading other people's code is, to my mind, critical when wanting to > learn clean code and great code structure. Knowing when to use > subclass and when to just implement some other class is really, really > important. > > I'm in the middle of negotiating to open-source these classes and > then, hopefully, someone can look at the code and make it pretty > again. ;-) > > But I'm more than glad that I could prevent them from using jQuery so > the network can hopefully be convinced to use MooTools everywhere. :) > > Cheers, Daniel > > On 2009-11-01, at 1/November, 3:12 AM, keif wrote: > > > > > Aaron, I kind of took it as that - honestly my first reaction was > > "geeze, that's a little harsh" until I thought about what you said a > > bit more. > > > I took it to mean - MooTools (and really, the community in general) > > encourages you to adhere to the "better" practices in your coding, > > period. It's not facetious, it's really an embodiment of the quality > > of code I tend to see from MooTools developers (and I'm being broad in > > that description, including random MooTools developers online that > > aren't in the group). > > > I had this conversation with a friend the other day, very honestly I > > was complaining about a contractor's jQuery code, which utilized a > > jQuery plugin they found. It was atrocious, and I made the comment > > about how I hated how the code was laid out (variables were all > > letters, no clearly defined structure, so it was more like they > > attempted to obfuscate it so if you needed to debug it you needed to > > reverse engineer the entire thing). > > > We came to the conclusion that the problem *isn't* with jQuery, it's > > with jQuery plug-in authors. Whereas with MooTools, we write classes. > > OOP principles really seem prevalent. jQuery plug-ins? They seem to be > > a "roll your own, no set standard, have fun." > > > Of course, the stuff said here could be expounded upon, clarified, and > > caveats and all that as well, I don't mean to say "all jquery plugins > > suck" or "all contractors suck" I'm saying - *in my experience* I've > > seen so much better, elegant, sexy code come from developers that code > > MooTools, and so much more shit code from people (notice, I said > > people, not developers) that code jquery. > > > -kb > > > On Oct 29, 11:26 am, Aaron Newton <[hidden email]> wrote: > >> my comment was a little facetious. it's quite easy to do most of > >> those bad > >> practices in mootools. if you're using classes, you probably won't > >> do half > >> of them without even trying. knowing when and how to write classes, > >> and when > >> and how to break things up into mixins and sub-classes and when to > >> alter > >> native prototypes are the types of things many mootools users don't > >> understand. > > >> On Thu, Oct 29, 2009 at 2:20 AM, keif <[hidden email]> wrote: > > >>> After reading it, this seems more like a "Improve Your JavaScript" > >>> versus really a jQuery specific article. I've been drafting a post > >>> over the general topic, I wouldn't mind plugging MooTools in it > >>> (especially Aaron's comment: "...or use mootools, which encourages > >>> you > >>> to program this way to begin with." > > >>> -kb > > >>> On Oct 26, 1:50 am, Nathan White <[hidden email]> wrote: > >>>> I would argue that #4 isn't a speed advantage and in some cases > >>>> harmful. > > >>>> I think some of the suggestions on selectors are valid and have > >>>> been > >>>> violated by mootools code in the wild. ( helpful tips) > > >>>> The suggestions about Dom insertion are also good. Again, general > >>>> good > >>>> practice that applies to all Dom js. Again I've seen mootools code > >>>> violate this principle. > > >>>> One practice "encouraged" by mootools that I don't always agree > >>>> with > >>>> is the use of .each(). Calling a function for each iteration > >>>> isn't the > >>>> greatest thing especially when fast tight loops are needed. > > >>>> The article also points out the use of window.addEvent('load') > >>>> instead > >>>> of window.addEvent('domready'). As a community I don't think we > >>>> point > >>>> out the differences enough. We too have a tendency of overselling > >>>> 'domready'. > > >>>> Event Delegation is a really good thing. It's sad that mootools > >>>> doesn't have this in the core. I'm guilty of not utilizing this > >>>> awesome technique as much as I could. I think the community could > >>>> benefit greatly from more awareness in this department. > > >>>> The points in the article about using references doesn't really > >>>> apply > >>>> to mootools if you follow the 'moo way'. Using classes gives this > >>>> one > >>>> to you for free. > > >>>> On Oct 25, 2009, at 9:01 PM, Aaron Newton <[hidden email]> wrote: > > >>>>> it's funny, almost all those suggestions can be summed up roughly > >>>>> as, "...or use mootools, which encourages you to program this > >>>>> way to > >>>>> begin with." > > >>>>> On Sun, Oct 25, 2009 at 4:14 PM, Dimitar Christoff < > >>> [hidden email] > >>>>>> wrote: > > >>>>>http://www.artzstudio.com/2009/04/jquery-performance-rules/ > > >>>>> I think most of it is really obvious and applies to mootools to a > >>>>> large > >>>>> degree - perhaps we can do our own best practices for effecient > >>>>> mootools > >>>>> code? in doing so we can also focus on particulars of our > >>>>> selectors > >>>>> system, coding to the pattern and inheritance, extending native > >>>>> classes > >>>>> when possible etc etc. > > >>>>> in any case, not a bad read this. for example, I had not > >>>>> considered > >>>>> the > >>>>> event bubbling performance implications - see 7. Leverage Event > >>>>> Delegation (a.k.a. Bubbling) > > >>>>> we could do it on wave or gdocs or something... ? > > >>>>> Regards, > >>>>> -- > >>>>> Dimitar Christoff <[hidden email]> -http://fragged.org/ |
||||||||||||||||
|
keif
|
In reply to this post
by Dimitar Christoff
Dimitar - I'm not disagreeing that MooTools is not an easy framework to jump, but it iterates an earlier statement I've made (many times) MooTools is for JavaScript developers. It's not meant for any random person to jump in and say "hey! I like what you did there, I want to do it" - jQuery is built on that kind of ideology (in my opinion) and as such their community is full of eager people who like to help out other people because they're all kind of "learning together" or whatever analogy you care to use (not 100% accurate, but I digress). MooTools is more for those that get JavaScript in general, or are furthering their knowledge. It's not a "beginners" community or framework in my opinion, and I was lucky to work with a couple great MooTools developers who helped me learn my way into it, which most independent users don't get. -kb On Nov 1, 1:42 pm, Dimitar Christoff <[hidden email]> wrote: > > I took it to mean - MooTools (and really, the community in general) > > encourages you to adhere to the "better" practices in your coding, > > period. It's not facetious > > I would disagree - it is kind of funny because it works in an odd way. The > problem is, the so called community (the core / more team + usual > suspects on the list and twitter) are quite subjective in one regard - > it all looks very easy from the top but paving the way for new comers > and relative new comers can be considered beyond what's called for. And > yes, resources are available but it's a different matter if they "read" > well to those that don't know what a dollar sign is yet or try to figure > why our $ is not the same as jQuery's... > > Once you "get/grock mootools" you are able to extract far more > meaningful help and advice and can appreciate and understand what the > others do. So these practices we speak of, you start to spot them, then > to question them and look them up. But often, there is no real > explanation available in the code/comments or on the list. > > For example, understanding namespacing but also understanding the impact > on overall performance, on noconflict mode and the extent to which a > mootools based prototypical script can play nice - it's a bit much to > get right from the source code of a snippet by davidwalsh.name :D > > I guess all I am saying is, not everything is obvious to those that > start from the ground up. What and how you code as a part of your > subconscious (or nott) routine often will not come easy to others... So > why not put a guide of sorts of the latest and best trends in js / > mootools / performance and how they can be applied to our code? > > This is the one thing we lack over jquery - better support and a broader > entry funnel imo, but there should be resources / guidelines for the > top-end too... > > Kind regards, > -- > Dimitar Christoff <[hidden email]> -http://fragged.org/ |
||||||||||||||||
Paul Saukas
|
In the end it is more what fits your mind the best. I have used Dojo, jQuery , and MooTools. I could understand them all , but for some reason MooTools just works with my train of thought.
Most of the code I did in Dojo is a nightmare. I had a bit of a time trying to get in to the flow with it, and as such wrote a lot of code that falls into the amateur hour. Same thing with jQuery but not so bad. I got to MooTools and all fell into place. Many people fit in better with a Dojo style of coding or some like the jQuery side, other Mootools. It can take them some time to find that out and in turn lead to alot of crappy code.(which the internet is glad to hold onto and share like an STD) I do not believe anyone is "better" then the other or more for people that "get javascript" or some such nonsense. The one you choose is the one YOU get. It is just that simple :) On Wed, Nov 4, 2009 at 10:03 AM, keif <[hidden email]> wrote:
|
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
