June 21st Office Hour Recap/Summary

Written By Olmo Maldonado, on Monday, June 27th 2011, 7:46am

As suggested by our community, we’re going to release a recap, or summary, of the IRC Office Hour after every session. We want to encourage you to join us on Tuesday’s at 11am EST in the #mootools IRC channel, but if need be let this be your medium to discuss your perspective and your own ideas (you can also discuss in the Google Group).

Topics Covered

  • MooTools 2.0 Community “Wish List”
  • MooTools Documentation
  • Flex Box Model
  • Require.JS and Namespacing
  • MooTools Roadmap
  • MooTools Feature: Accessors
  • Model Change Events
  • MooTools 2.0 Site
  • MooTools UI and Mobile
  • Event Delegation in Core
  • Github Issues

MooTools 2.0 Community “Wish List”

We created a document and shared with the IRC channel a “wish list” to add requests of what MooTools 2.0 should include. You can find the wish list here. Please add your own requests. Periodically we’ll check the list and approve items for 2.0.

MooTools Documentation

We talked about our efforts to improve the documentation. We were suggested in the channel to improve the argument list in the docs and include inherited properties and methods (plus link to the parent class).

We also want to make the experience more viral and social and we’d like to include social plugins (Facebook and Twitter). A comments section akin to PHP’s plus heavy moderation to have quality comments and shared experiences.

Analytics will also play a major role as we’d like to improve feedback. We’d like to know which methods and classes are most viewed, liked, and commented. Likewise, we want to make it easier for you to find what you’re looking for. Better SEO as well as navigation and search inside of the docs.

While you are in the documentation, we are also adding inlined jsfiddle so that you can run the examples/demos and modify them on the fly. This also means that you can contribute your own examples/demos.

Of course, the above is a lot of work and we welcome your participation. Darren Waddell has stepped up and already started working on this. Take a look at his repository (fakedarren/mootools-docs) and please fork. User, kpobococ, is already working with Darren thanks to the office hour.

Flex box module

A user had a question about the “wrapping” of the UI so that it extends to the complete window. It’s not built-in to MooTools, but we gave him a few suggestions on how to accomplish this. Ryan Florence mentioned his mootools-wallpaper and a jsfiddle example.

AMD, requirejs, namespacing

First, some context. require.js is a “file and module loader” which implements the Asynchronous Module Definition (AMD) CommonJS specification. This means that you can define modules and require (load) them only if they’re necessary. The philosophy is aligned to ours. We’ve never wanted our users to download the complete repository and load it blindly into a page. We’ve supported modularity, and speed, since day 1. Rest assured that MooTools 2.0 will be require.js ready out of the box.

Namespacing, is a loaded term. It may mean to “sandbox” MooTools so that it doesn’t mess with prototypes. Namespacing may also mean that you can apply, or install, methods into any given object. We’ll make a separate blog post about this, but it’s time to let the cat out of the bag.

We would like for MooTools 2.0 to play nice with everyone. This is a huge departure from 1.x days, but we’d like to position MooTools 2.0 so that you can drop it in any environment (that JavaScript can be run) and it will Just Work™.

Valerio Proietti has started to work on this in his own define-2 branch and we’re looking to you for feedback and opinions. Please fork and send feedback. Now is the time to make your voice heard. Once we release 2.0, there’s no going back.

MooTools Roadmap

And this brings us to the roadmap. Again, well deserving of its own blog post. Here’s the official word from Valerio, himself. We’re going straight to 2.0. There’s no date, yet, on when this will happen but a lot of work and time is being put to get it out the door.

This would be the time, for you to volunteer your time.

Oh and don’t run around frantically. 1.3.x will continued being developed but released as bug fixes and any improvements provided by the community or downgraded from 2.0.

MooTools 2.0 Feature: Accessor

Still in its infancy this pattern is very powerful. It’s deserving of its own blog post, but here’s the summary: with this pattern you can define and lookup functions and properties that are usually Objects now, like Class.Mutators or Element.Properties. Besides simple lookup, it can also do a match so a ‘protected’ Class Mutator can be defined so a Class method can be defined as ’protected foo’: function(){ so that the method cannot be run outside of the class. Have a look at the source.

Model Change Events

Someone had asked to support events for when properties change in the form of change:foo. It’s doubtful we’ll have this, but developer, verylastminute, has already worked on something that might serve in the mean time: ElementSpy.

MooTools 2.0 Site

As you might have expected, there will be a new site for the launch of 2.0. We’re not yet in implementation stage, but we have screenshot of what it might look like. If you’d like to get involved in the design (for some street cred) join us in the IRC channel to get in touch with Nathan Querido, from QueridoDesign, since he’s leading that project.

MooTools UI and Mobile

There’s a strong request for an official UI and Mobile projects. Although we are not promising that we will get around to the UI and Mobile prior to 2.0 release, we do agree on having them. For now we’re supporting projects that fill this need.

For the mobile, we’re interested in jpdery/moobile-core and cpojer/mootools-mobile. Add your projects in the comment section.

For UI we have our own ART project which is almost ready to be released. Missing documentation and testing. There’s also projects we’re interested in: inviz/lsd, anutron/behavior, JxLib, and sixtyseconds/mootools-interface. Add your projects in the comment section.

Event Delegation in Core

We’re also promising that Event Delegation will be in Core before 2.0 is out the door. Still unknown if the API will change between 1.3.x and 2.0, but let’s revel in the news!

Github Issues

Again one of those, “deserving of its own blog post” we’re moving from Lighthouse Tickets to Github Issues. This means that we will accept any new issues in Github and discourage the use of Lighthouse. We will disable Lighthouse after we’ve migrated.

Next Office Hour

As you’re now aware, the MooTools Office Hours are very fun and informative. Remember that we’re having another this:

Tuesday, June 28th 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/.

9 Responses to “June 21st Office Hour Recap/Summary”

  1. André says:

    MooTools UI (one more)

    http://mochaui.org/demo/

  2. steve says:

    Just a question about your unbagged cat…

    I thought the reason why Mootools is a framework is because it modifies Javascript to be better, including extending built-in types. This is essential for being able to chain operations on Arrays with function calls, instead of jQuery’s weird nesting of $.functions?

    Does that mean that mootools is being rewritten to a more modern version of Javascript (1.5?) and that IE will be deprecated, or that mootools is being rewritten to remove its main advantage of a systematic and clean extension of Javascript as a framework?

    I expect that it would be possible to opt-in and have it both ways, but I’m concerned about what this means for the main code base or what plug-in developers would have to write in order to comply with any limitations for backwards compatibility?

  3. dreadcast says:

    Moobile !!!

  4. Thomas Aylott says:

    @steve Fear not, we’re taking all those concerns into account and a whole mess more.

    We are very very serious about keeping easy compatibility with 1.x code.

    Imagine this: you hit the builder page and you have a checkbox or something ‘Extend Natives by Default?’. If you uncheck that box you’ll get a download that doesn’t extend natives. But then it’s still only one line of code to extend them later if you want.

    As for The Forge, pretty much everything will continue to work with the 1.x compatibility mode. But pretty quickly I’m sure many things will begin to support both modes of the framework using require.js.

    Awesome Things are happening, but don’t worry about us breaking all your stuff, we love you guys.

  5. ibolmo says:

    @steve yeah this is all still very experimental. It’s certain, however, that you will not see $.functions. You will see generics in use, though. Instead of [0, 1, 2, 3].forEach(...) you may want to use Array.forEach([0, 1, 2, 3], function(value, key, array){... if you’re writing a plugin or Array.install(); [0, 1, 2, 3].forEach.... in your application code.

    The bottom line is that we’re trying to put MooTools into “friendly” mode by default and let you, the developer, decide if you’d like to extend the natives.

    I personally will develop public source code in generic form and have my code and environment — which I control — bend to my will. :D

  6. TOFU says:

    “Friendly mode” should be a Core feature only and OFF by default. Let “users who know what they’re doing” enable it so they can run MooTools Core in different environments. Plugins however should keep on using extended natives unless they make sense to be used in bookmarklets or node.js.

  7. Bart Garbiak says:

    I fell in love in Mootools exactly because it was extending natives. Sure, the solution had some shortcomings, but “[1, 2, 3].each…” kind of syntax was the thing that made writing apps in Mootools so intuitive. I’m a bit sad to see it go (let’s not fool ourselves: in the long term it’s inevitable). However, I have to admit that working with Types in 1.3 isn’t that bad either.

    Here’s an idea: “coffeescriptesque” compiler for Mootools ;)

    @TOFU: Plugins extending natives by default automatically make any application that incorporates them extending natives too. Plugins written in “safe mode” gives you free choice.

  8. TOFU says:

    @Bart Garbiak I know, but “safe mode” is slow, isn’t it? My point is you should be able to use Core everywhere. If you plugin makes sense to be used in node.js or a bookmarklet, ok fine, use generics. This should be an option (not enabled by default) without any drawbacks. I’m just worried about Core performance for the milk.

  9. Keijo says:

    Great blog post Olmo! There should be “Planet Mootools” in new web design.