June 28th IRC Office Hour Recap/Summary

Written By Olmo Maldonado, on Monday, July 4th 2011, 8:37pm

Every week the MooTools developers have an IRC office hour meeting where they work together to listen to your feedback, answer your questions, and develop on MooTools. We do this every Tuesday at 11am EST at #mootools Freenode IRC Channel. Everyone’s welcome so join us tomorrow.

Recap

Last week’s office hour was dominated by the experimental define-2 branch by Valerio. This branch has the experimental support of Asynchronous Module Definition (AMD) and also has the proposed direction of MooTools 2.0 as mentioned in the previous blog post.

From the discussion in last week’s office hour, it seemed that there was confusion on the implications of adopting Valerio’s 2.0 branch. In particular there were concerns for: compatibility, native extensions (and minimum ES5 polyfills), chainability, and style.

At first, 2.0 will likely not be compatible with 1.3 without a builder and an upgrade script. Since we’ve yet to cross this road, please be vigilant of the changes and discussion that are underway. As always, rest assured that we would like to make your transition into 2.0 as easy and immediate as possible.

Without a dedicated blog post, I’d like to recap that there is a divide between the community and even the MooTools developers about the possible decision to not extend native objects (e.g. Array, Number, String, …) by default. One side of the argument is that this is a 180 degree shift in MooTools style and philosophy and that it ruins competitive differentiation (a marketing term). On the other side of the argument is that this is necessary to stay relevant in the discussion, that we’ve cornered ourselves between a rock and a hard place and that we just need to be better. Valerio had even quoted Steve Jobs as a perfect explanation on his position.

Instead of going further and making points for either argument, it’d be more appropriate if we make a definitive post on the matter.

Next Office Hour

The discussion is still not done. If you’d like to give us your $0.02 on the matter, we welcome your thoughts and concerns. If you’d like to contribute to the 2.0 Wish List, add your suggestion or talk to us on IRC. Remember that we’re having the next office hour this:

Tuesday, July 5th at

05:01 - Honolulu (Hast UTC-10)
08:01 - San Francisco (PDT UTC-7)
10:01 - Chicago (CDT UTC-5)
11:01 - New York (EDT UTC-4)
12:01 - Rio de Janeiro (BRT UTC-3)
16:01 - London (BST UTC+1)
17:01 - Vienna (CEST UTC+2)
20:31 - Mumbai (IST UTC+5:30)
23:01 - Hong Kong (HKT UTC+8)
00:01 - Tokyo (JST UTC+9)
01:01 - Sydney (EST UTC+10)
03:01 - Auckland (NZST UTC+12)

Add it to your Google Calendar.

We’ll be in the #mootools freenode.net channel.

Guidelines

We did very well last week in following the guidelines. I’ve included them in this post as a reminder.

  1. Please use jsfiddle.net and keep your code with minimal boilerplate — get to the essence of your question
  2. Stay on topic. Let’s keep the chat around MooTools and how it interacts with your code and the rest of the JavaScript ecosystem.
  3. Be courteous and helpful with others. We are not guaranteeing that all of us will give you our undivided attention during the hour (we are also working!). If you can answer a question (as best as you can) it will really be helpful.
  4. Sharing is caring. Share the room, but also share the event. Post to twitter, Facebook, your blog, and tell your parents. We want to foster growth in our community. This is the chance to participate and to help.

Tips

Use this button to add the open office hour to your Google Calendar. You’ll need to setup the event so that it repeats weekly.

If you don’t have an IRC client you can use http://webchat.freenode.net/.

18 Responses to “June 28th IRC Office Hour Recap/Summary”

  1. Olivier El Mekki says:

    Could you develop why native extensions should be dropped? I found it quite sad to see extensions on Object, but I don’t get why we should not use this feature on other natives.

    Also, just to be sure, can you confirm (or infirm) that the pseudo native Element will be kept? I’m not totally sure it’s native extension related, but one thing that always annoys me with jQuery (the “do not extend natives at any cost” framework) is the fact that $(‘#id’) == $(‘#id’) => false (whereas in mootools $(‘id’) == $(‘id’) => true, of course).

  2. Tim says:

    There is 1 valid reason to drop natives and still hold the Mootools philosophy: Let it work, and let it work smooth.

    If this is a reason, then I agree for 100% to drop natives. There’s no need for a bicycle when you can make a car yourself, or is it?

  3. alpha123 says:

    If you drop native extensions, I’ll a) strangle you, then b) just use my own stuff (which ironically doesn’t extend natives, but hey, that’s why I use Moo; don’t ask about my reasoning).

    Dropping native extensions would make MooTools just another JavaScript library. Extending natives makes code so much more pleasant and cleaner. The only thing you’d have on your side if you dropped them is Class.

    How would you do things without native extensions? Have a big MooTools namespace so your code looks like MooTools.Array.each(myArray, myFunc)? I nearly vomited writing that. Moo provides so many utility methods that’s just not practical. Here are a few reasons to keep native extensions:

    • They are way cleaner.

      MooTools.Element.inject(MooTools.Element.grab(new MooTools.Element(‘div’), new MooTools.Element(‘p#theP’)), MooTools.id(‘myElem’))

      versus

      new Element(‘div’).grab(new Element(‘p#theP’)).inject(document.id(‘myElem’))

    • They are more natural. MooTools.Function.bind(myFunc, obj) is harder to understand than myFunc.bind(obj). Granted, that’s not really the case in a simple example, but dozens of method calls like that? Really?

    • They make code shorter. MooTools code is dense because of native extensions. See the example for the above point.

    • They provide easy namespacing. Much better than stuffing everything into MooTools.XYZ namespaces like I’ve been doing.

    • They are elegant. On your front page it says “… It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API.” Removing them would make code clunky.

    • They are unique. Only Prototype and MooTools extend native objects. This is a big selling point, especially when you give some demo code.

    • They can provide polyfills for ES5 methods.

    And there is no reason not to. Extending native types is not very popular these days, probably only because they conflict with anything else that extends natives and incompetent programmers lose when you extend Object. Both of those are weak arguments. First, anything that extends natives is likely to have the same meaning for their methods (I can’t imagine Array.filter being used for anything else), and more importantly, WHO USES MORE THAN ONE LIBRARY ON THE SAME PAGE? Sure, start talking about widgets and stuff, but those often only use jQuery. Like I said before, Prototype and MooTools are the only major libraries to extend natives. And the idiots who don’t use hasOwnProperty in their for loops deserve to be clobbered. MooTools makes JavaScript how it should be. “MooTools is a framework that attempts to implement JavaScript as it should be (according to MooTools’ authors).” (from jqueryvsmootools.com). Removing native extensions would make it more of a toolkit and way less pleasant to use.

    Okay, cool down, deep breaths…

  4. alpha123 says:

    Er, wow, that was more of a rant than I anticipated, partly because it didn’t preserve newlines in my list. Just pretend there is a newline before every hyphen in that part.

  5. ibolmo says:

    @alpha123 I went ahead and cleaned your comment. I hope it’s easier to read now.

    First, please no panicking. As mentioned above and the previous post, we’re intentionally keeping this in the down low. It’s still very experimental, but it seems that we need to improve our communication on how awesome this is.

    We’re working on two articles for the blog to help clarify this. First, I’m working on a side by side comparison between 1.3 code and 2.0 code. More to come.

    Second, we’re working on an extensive article to explain the reasoning and how this is incredibly cool for 2.0.

    At first I’ll clarify a few things, but please be patient and/or read the code: kamicane/mootools-core/tree/define-2. It’s the best way to understand.

    1. You don’t have to do MooTools.Function.bind. If you so choose to you may do Function.bind(fn, context);. No namespacing.
    2. You don’t have to do use generics (as above). As of right now we have an install method on the natives (e.g. Function). That when you call it: Function.install() you’ll be able to go back to 1.3.x use: (function(){}).bind(context);.
    3. ES5 polyfills are there as generics. We’re considering adding a ES5.js, or similar, for those that want to add them to the natives by default (via install, for example).

    I’m sure I missed something from your arguments/points. But, I hope the above gives you some relief. We’re not out to render your code useless or horrible. Remember, we’re MooTools. We make working on JavaScript fun™.

  6. ibolmo says:

    Oh and regarding your code examples. Here’s my version of yours:

    1.3x

    new Element(‘div’).grab(new Element(‘p#theP’)).inject(document.id(‘myElem’))
    

    2.0x

    var Element = Node.Element; 
    new Element('div').grab(new Element('p#theP')).inject(Node.select('myElem'));
    

    2.0x with require (complete example)

    require(['DOM/Node'], function(Node){

    var Element = Node.Element; 
    new Element('div').grab(new Element('p#theP')).inject(Node.select('myElem'));        
    

    });

    Pending Valerio or Arian correcting me, the above should illustrate how it’s not so much different than 1.3x.

  7. alpha123 says:

    Yeah, okay, I overreacted. Thanks for cleaning up my post. :)

    Yes those do give me some relief. Still, install()-ing everything I want to use doesn’t sound pleasant. Could there be some way to automatically install() everything? Like <script src="mootools.js" data-install="all"></script> or <script src="mootools.js" data-install="Array,Function"></script> or something like that.

    I’m looking forward to reading the articles when they come around.

  8. ibolmo says:

    Yeah I forgot to mention that. We’re, probably, including the ability to install all.

    If you notice, one of the most attractive things from the above is the power of choice. With 2.0 we’re giving you the developer even more choice to do with MooTools what you want. If you want MooTools to work anywhere, then you’re best to use generics (think plugins, or projects that have to play nice — ads, frameworks, tools, etc.). Otherwise, go nuts and install them so you can enjoy 1.3.x style.

    Again more to come.

  9. alpha123 says:

    Okay, the 2.0 code isn’t so bad, but Node.select seems stranger than document.id or $, and aliasing things like that feels so YUI-ish.

    What’s the reason behind not making native extensions the default?

  10. alpha123 says:

    Okay, forget about my last question, presumably the answer would just be the “power of choice” thing.

  11. ibolmo says:

    Yeah the API/interface is not yet solid for some things. Perhaps you can think of a better interface? We’re definitely not interested in more than 2 levels of (YUI-esque) namespacing.

    And yeah, that’s the reason. Although, Keeto has suggested that there might be a way to flip the burden on us rather than our users. He had mentioned an uninstall — similar to install — that would take out the native extensions if you want to be in a friendly environment. I’ll let him, however, write a more detailed explanation in code or an article.

    We’re interested in your feedback and we’re glad that everyone has been passionate. We’re fortunate that our user base has strong developers that understand the importance towards style and ease. Hopefully, you’ll join us in the IRC Office Hour next week and/or start contributing with tickets, code comments (reviews, or your own pull requests in github.

  12. alpha123 says:

    Just Node('myElem') seems better than Node.select('myElem'), though I have no experience with CommonJS, so I don’t know if it lets you use functions instead of objects for root namespaces.

    Uninstall seems preferable to install, though with a way to automatically install everything the difference wouldn’t be huge. I think cases where you have to play nice are less common than the cases where Moo is the only thing on the page, so it makes more sense to have them installed by default. Even if they aren’t installed by default an uninstall method seems like a necessary counterpart to an install method.

    I plan to take part in the IRC Office Hour next week (I slept through it this time :P); I’ll look at the define-2 code in the meantime.

  13. Olivier El Mekki says:

    @ibolmo : I love the keeto way (uninstall), sounds much like a “compatibility mode”. Isn’t the “power of choice” all about that? (I see no special reason to use a less elegant syntax other than preventing conflicts, but I’ll wait for your articles).

    Of course, that may be a problem if an other lib is loaded before, extends a native and then mootools overwrites it, call uninstall and remove everything. But I guess this problem can be avoided by storing the function if it exists prior to mootools extension, and reset it when calling uninstall.

  14. Dimitar Christoff says:

    The key difference to me is what you do to devs who maintain an existing codebase and need to stay current. Showing how the API is not much different is just unfair. the PUBLIC API needs to remain as consistent as possible. Your small differences can amount to countless of hours of refactoring, spread over 10s of thousands of lines of code for some of us. I had to do this to convert a site from 1.11 to 1.3 w/ compat and it sounds as if things may be headed this way again. Take joomla, for instance. How long did it take them to move over to 1.2/3 - despite of all the upgrade plans/paths and upgrade helpers. How many plugins are likely to be rendered dead? If you have come to the decision that mootools is no longer current and want to do things differently, wouldn’t it make more sense to start over as a new library? Re-inventing it and trying to be compatible will only hamper the new development anyway.

    So, is the 1.3 fork going to become redundant?

  15. ibolmo says:

    @Dimitar Between minor versions (1.3, 1.4, 1.5), I’d agree that we should maintain the API. Major versions (1.x, 2.x, 3.x) it’s understood that it’s a major change and you’re likely to run into upgrade problems. This is something we’ve corrected and have improved on since 1.2. Going from 1.1 to 1.2 was a big headache, but I think you can agree that going from 1.2 to 1.3 was much easier.

    Going from 1.3 to 2.0 will not be a picnic and that’s why we’ll continue to support 1.3. Besides, 2.x will not be that much different. I’ll post the comparison soon. It’s going through reviews right now.

    Likewise, there’s a few of us in MooTools that would like to work with Joomla (and we’ve had before) and other applications to use upgrade scripts, compat layers, or simply to help them change the code. More on this later, but again I’ll reiterate that it’s not our intention to make your lives and work difficult.

    I didn’t understand your last question.

  16. Dimitar Christoff says:

    thanks for the clarifications.

    on the last question : basically since 1.2 came out, there had been a single update to 1.11 to 1.12 and it was to patch a breaking change deemed critical. is this the likely fate of 1.3 now?

  17. ibolmo says:

    @Dimitar My personal opinion is that we should have a set time of “support” for 1.3.x. We’ll discuss the length and the definition of support for 1.3.x and get back to you guys.

    We could definitely use more contributions (pull requests) for 1.3.x and 1.2.x and 1.1x if bugs are found. At the moment, we try to trickle fixes to older versions, but it’s true it hasn’t been a disciplinary. I am aware, and I’ll bring it up so that we can be conscious about this when similar moments arise.

  18. Metal3d says:

    Ho god I was not here to say you: “Please, never drop natives !!!” I know that natives can be a bit heavy… but how coding is nice with that !

    I agree with alpha123, each point he said are exactly my opinion. So… what’s new ?