But before we can do that, we need your help. We’ve set up a form so we can gauge interest in a MooTools Conference. All you need to do is take a minute and answer the questions.

We’ll keep the form up until next week, but make sure you answer quickly so we can start planning this awesome Official MooTools Gathering (or OMG—which might or might not be the name of the conference).

It was late 2009, the MooTools Forge (plugin repository) was just released, and I was learning JavaScript and MooTools by creating many plugins. This is already the first form of contributing to the MooTools project: releasing code that might benefit others. The cool thing about this was that I also helped other people on GitHub that released their MooTools plugins, and thanks to this interaction I learned even more.

At the same time the MooTools Core developers were building MooTools 1.3. I closely followed the developments and noticed that a few things were still missing. One thing that seemed easy was the documentation. So, in some spare time I dove into the MooTools source code, looking through the commit history to see what changed, and update the existing MooTools 1.2 documentation accordingly. If I remember correctly a pull request on GitHub at that time was basically a private message to the MooTools devs, so it was exciting whether my changes would be accepted. Fortunately contributing to the documentation is always helpful, so my changes got merged!

Because MooTools 1.3, at that time, was fully under construction, there were many loose ends that were easy to fix. I got invited to talk to the MooTools devs on IRC, and got involved more and more. So I started working on MooTools More 1.3, which was something else that was not updated for the new 1.3 release. This was a great way to learn how the internals of MooTools work: we had to look into MooTools Core to know how to effectively update the More code, or even fix things in MooTools Core, but at the same time it wasn’t too difficult yet.

Later that year I went to the MooTools Hackathon in London, where we finalized the MooTools Core 1.3 and More 1.3 releases which were released later that year. I also got a nice place on the MooTools developers page!

So how does my nice story tell you how to contribute? Basically what I did is look if something was blocking the release for MooTools 1.3, went ahead and fixed that, just by spamming the MooTools devs with new pull requests.

The most important point is direct communication with the developers. This mainly happened on IRC, but is still valid. Join #mootools, say you want to help out with something, or did something, explain again why we should merge your pull request. This is really the best way to get started. If you don’t directly see a loose end where you can help, the MooTools developers probably know something interesting for you.

Currently there are a few aspects where you can help. If you have followed the development on GitHub you might know about prime, elements, agent, moofx etc. There is still some stuff (especially website/documentation related) to be done for a real release. See also the roadmap on the Prime Wiki. But it’s also perfectly fine if you like to work on the current version of MooTools Core. The idea is to release a MooTools 1.5 with mostly bugfixes, and a few deprecations. The biggest chunk of work for 1.5 is a review of bug reports and pull requests.

If you’re not really comfortable contributing code or documentation directly, writing blog posts, tweeting about MooTools or helping other people on the MooTools Mailing List, #mootools on IRC or stackoverflow are really great ways to contribute too.

I would like to conclude with the benefit of contributing to MooTools or Open Source in general. I’ve learned so much and you get the opportunity to do things right. Apply testing techniques, try new technologies, learn more than you want to know about IE7 or other interesting browser behaviors. The things I learned by contributing MooTools simply made me a better developer.

Edit: we created a wiki to collaborate on design and websites for MooTools projects on GitHub. So if you’re into that kind of thing, this is another great way to contribute!

Firefox 18 already ships this new version of contains. This is not a problem for MooTools 1.3.x and onward, but this breaks MooTools 1.2.5, especially the code inside the MooTools framework that utilized this method, like selectors.

This new 1.2.6 release solves these issues by overwriting the native version with the MooTools version of String.prototype.contains.

For the next MooTools version, 1.5, we will use the standard ES6 version. If you rely on the old behavior (which is only when you use the second argument), it will be possible to use the old version through the compatibility layer.

• Download 1.2.6
• Or upgrade to 1.4.5
• See changes on GitHub

Découvrez Mootools - Un framework JavaScript pour des sites dynamiques et interactifs (Discover MooTools - A javascript framework for dynamic and interactive websites) is aimed at beginner and intermediate developers who wish to create spectacular effects using MooTools. This book does not go deep into topics that would likely only confuse you, but instead it keeps everything simple and provides many clear cut examples and illustrations that will facilitate your understanding. Priced at 12.5 Euros (~15$) it’s a must-have if you’re looking to learn MooTools.

As the author says, it does not cover the entire framework. Instead, Xavier Lecomte selected the most commonly used MooTools pieces and explains them in detail. Throughout this book, you’ll learn how to create classes, handle DOM elements, create AJAX requests and create effects using Fx classes. The latter is probably the most discussed topic of this book as it goes through almost every Fx-based class in MooTools. When it comes to Fx classes, the most complex part is probably options. Although they are well named, they could be difficult to grasp, especially to the novice user. This book makes this type of functionality very clear by explaining all the options for each class discussed, at times, through the use of illustrations. The Fx chapter wraps up with a complete example, where the author builds a pong game using tools explained throughout the chapter.

Finally, the book discusses work done by the MooTools community. Although it does not go deeply into each project (most of them would require a book on their own), it gives a good idea of what MooTools is able to offer.

To conclude, if you’re a native French speaker interested in learning MooTools, this book is a must-have, especially at that price. I hope Xavier Lecomte will continue writing about MooTools, the in-depth detailing of this book is amazing and will certainly benefit many.

iOS 6 Theme

The iOS theme has been updated to closely match the recent changes in iOS 6 for both iPhone and iPad. This release also addresses the updated border-image syntax that casued issues with buttons inside bars or alerts. Finally, elements that were not hardware-accelerated (using only translateX or translateY) are now as smooth as they should be.

Android Theme

This release includes a basic Android 4 theme. This is still a work in progress and, since my testing devices are limited, I cannot guarantee it will work well on all devices. Any tips you can share about improving speed on Android would be greatly appreciated.

Transitions

Two more transitions were added: Cover.Page and Cover.Box. They aim to replicate modal view transition on iPad. The cover transition, using the Android theme, has also been customized to match the native Android look and feel.

Simulator

The simulator’s UI has been improved. It’s now less intrusive and provides a zoom functionality. Keyboard shortcuts were also added; you may now use the arrow keys to zoom or rotate. Settings (such as orientation, zoom and options) are now saved on a per-device basis so you won’t have to zoom out every time you use the iPad device on your laptop.

The Boiler Plate

Touch icons and startup images for all sizes have been added to the boiler plate.

Moobile.Component.defineAttribute

A minor improvement, but an improvement nonetheless. For those who were tired of writing data-option-style-name, data-style is the new alternative. It’s now possible to specify a behavior for certain attributes on a component thanks to the Moobile.Component.defineAttribute function.

The Future

The next release will geared towards adding content. Tab views, split views and on-off switches will be included in the new version. I’m also planning to improve the documentation, add more examples and make things easier to understand.

Requests

If you have any requests, you’re welcome to contact me through the GitHub page. I’ll be glad to listen to your requests and, hopefully, improve your experience working with Moobile.

Moobile is developed by Jean-Philippe Déry and is hosted on moobilejs.com

Arian Stolwijk - https://tinker.io/9d871/1

Arian impresses once again with some beautiful code. It’s also a good example of how to use requestAnimationFrame and how to calculate FPS.

Mickele Moriconi - http://jsfiddle.net/czsEe/

Mickele’s example showcases a disembodied arrow to indicate the direction in which the cursor is pointed as well as keyboard navigation and event delegation.

Pete - http://jsfiddle.net/NHhqA/, http://jsfiddle.net/DRgNd/, http://jsfiddle.net/2T8v4/, http://jsfiddle.net/u922h/

Pete really shines in this challenge; presenting many concepts and explaining the differences and benefits of various approaches to efficient design of his examples. If nothing else, read through his explanation of the coding approach he has taken in his third and fourth examples.

Corto - http://jsfiddle.net/corto/qrPav/7/

Corto used CoffeeScript and jQuery to build his example. Once you get over all the @ symbols, it’s really quite concise. :)

The purpose of this was to explore different means of input-based drawing with SVG, DOM and canvas. While we would have like to see more DOM and SVG implementations, there were many good examples of canvas usage!

We would like to thank everyone that participated - it was fun to see so much conversation and collaboration around a fun JavaScript challenge. Be sure to check out the Challenges category of blog posts for new challenges every week!

Christop Pojer - https://tinker.io/66bb4/4, https://tinker.io/c341c/8

Christoph’s example showcases a combination of concise code and CSS3 animations to make the game fun and challenging. It makes minimal use of MooTools-provided methods and is generally a good example for how to code similar tasks.

The second example is just hilarious! Give them a bash…

haliphax - http://jsfiddle.net/YYyRD/

Haliphax’s example showcases a way to create delegated events in plain old JavaScript. It also makes good use of querySelectorAll().

Lionel Garcia - https://tinker.io/f5794

Lionel’s code is beautiful. It demonstrates a common way to package program code in a single object and provides a lot of interface elements over and above the brief or the competition. I had a lot of fun playing this one.

Kevin Western - https://gist.github.com/3229945

Kevin demonstrates a port of the game to the Dart language. I am still amazed every time I see a 50 LOC Dart script and its 1800+ LOC JavaScript equivalent.

Pete - http://jsfiddle.net/tqvMc/

Pete’s example is the shortest, having hard coded the HTML elements and using a few minor MooTools convenience methods. Still a good job!

Cristian Carlesso - http://jsfiddle.net/kentaromiura/rUqJ7/21/

Inspired by Christoph’s example; Cristian adds variation by allowing target team selection and sound.

The purpose of this challenge was to introduce event delegation and to utilise some of the knowledge learned from the previous challenge. We would like to thank everyone that participated - it was fun to see so much conversation and collaboration around a fun JavaScript challenge.

Be sure to check out the Challenges category of blog posts for new challenges every week!

This week’s challenge will be to create a memory game using shapes, colours, numbers or anything really, so long as it involves memory. Refer to the following diagram…

The basic idea is that your game should present a series of colours, shapes, numbers, etc. for the user to then repeat. If they get the sequence right, the next level starts, which increases in difficulty.

Hint: you should store the order of the sequence so that it can be reused when checking the user’s input. Make things interesting by allowing keyboard navigation, or varying the elements used from level to level.

You can make your solutions as intricate or as basic as you wish!

As before; post your solutions in the form of links to jsfiddle, tinker or jsbin (in the comment section) and we’ll update this post with the solutions that we think tackle the problem in ways worthy of mention.

Happy coding!

EDIT [2012/08/29]: We are closing comments and reviewing submissions. We will follow this post up with a review of our favourites and what they teach us about the task and JavaScript development in general.

This operating system had just such software, in a number of different variations. One of these created the “illusion” that the observer was travelling through space, passing stars. This is the subject of this week’s challenge.

Refer to the following diagram…

…not very helpful.

The idea is that “stars” appear in the center and move to the bounds of the viewport. However you choose to create this effect is up to you.

Hint: you can achieve the effect using elements, canvas or SVG but so long as they move outward you are on the right track. What we’re interested in is how efficiently this can be coded and how little yours leaks! Try spicing things up by adding interactivity or variation of any description.

You can make your solutions as intricate or as basic as you wish!

As before; post your solutions in the form of links to jsfiddle, tinker or jsbin (in the comment section) and we’ll update this post with a link to a review post detailing solutions that we think tackle the problem in ways worthy of mention.

Good luck!

EDIT [2012/08/22]: We are closing comments and reviewing submissions. We will follow this post up with a review of our favourites and what they teach us about the task and JavaScript development in general.

The good news is, you can optimize MooTools builds to remove specific (IE) code! Packager has been used to concatenate builds since MooTools 1.3. Removing certain code blocks, like MooTools 1.2. compatibility or specific IE code is one of the features of Packager. Lets see how it works. We begin with downloading Packager.

Note: the commands are tested on Ubuntu, and probably work fine on a Mac too. However some details might be different on a Windows machine.

Getting Packager

Packager is available on GitHub, and can be pulled with git:

~/$ git clone https://github.com/kamicane/packager.git

or downloaded directly.

To test if Packager is set up correctly, open a terminal window, cd to the packager folder and type ./packager —help. If this doesn’t work you might need to install PHP first because Packager is written in PHP.

~/$ cd packager
~/packager$ ./packager --help

It’s a good idea to add an alias in your ~/.bashrc file or create a symbolic link to /usr/local/bin so you can just type:

$ packager --help

Getting MooTools Core

The second thing we have to do is to get the source code of MooTools Core. It doesn’t need to be placed in the same folder as Packager. MooTools Core can be pulled with git:

~/$ git clone https://github.com/mootools/mootools-core.git

Unless you like to use the cutting edge, you probably should checkout the latest tag, at the moment of writing 1.4.5 to use a stable release:

~/$ cd mootools-core
~/mootools-core$ git checkout 1.4.5   

or you can download the latest version from the GitHub download page.

Registering MooTools

Once we have pulled the MooTools code, we need to register it. Registering a package is done with the packager register command:

~/mootools-core$ packager register .

If everything is correct, the terminal should output some text saying something like the package Core has been registered.

At this point we can create various MooTools Core builds, depending on your needs. Lets look at some examples.

Building MooTools

In the previous step we have registered MooTools Core as Core, all MooTools Core components are now under the Core package. Wherever you are, you can build a MooTools build. An example of building the DOMReady component from the Core package would be as follows:

$ packager build Core/DOMReady

To build all components, the * wildcard can be used:

$ packager build Core/*
$ packager build Core/* > core.js

The > redirects the output to save to a file.

Optimizing MooTools filesize

To exclude certain blocks, we can use the -blocks option. This is an command that removes most Internet Explorer 8 or lower specific code:

$ packager build Core/* -blocks IE '!ES5' ltIE9 ltIE8

Note that the !ES5 is in single quotes because otherwise the terminal would interpret the ! as some other command.

As you can see there are several block types. Here’s a list of all the block types and what they’re used for.

• 1.2compat this is the MooTools 1.2 compatibility layer for old scripts that use MooTools 1.2
• 1.3compat for API changes between 1.3 and 1.4
• !ES5 this adds ECMAScript 5 methods, like Array.prototype.{forEach, map, every}
• !ES5-bind if it should include Function.prototype.bind. This method wasn’t natively available before Safari 5.1.4.
• IE used for all Internet Explorer versions (may include IE9)
• ltIE9 IE8 IE7 and IE6
• ltIE8 IE7 and IE8
• ltFF4 code for old FireFox browsers (only for set('html') and table elements)
• webkit code for webkit (currently a button type property bug)

In the code the blocks are defined as something like /*<IE>*/ … code … /*</IE>*/, so you could checkout the the code for more details, and decide whether you need it or not:

Real Life Test Case

What if we want to build an application for modern browsers only? We start it from scratch so we don’t need compatibility code and we like to use MooTools Class and Element for the basic stuff, and use an external library moofx for CSS3 animations. To initialize everything we also need DOMReady.

The packager command would look like:

$ packager build Core/Class \
               Core/Class.Extras \
               Core/Element \
               Core/Element.Event \
               Core/DOMReady \
        -blocks 1.2compat 1.3compat '!ES5' '!ES5-bind' \
            IE ltIE9 ltIE8 firefox ltFF4 webkit > core.js

From GitHub we have downloaded a moofx build which is in moofx.min.js. We can simply append this file to the freshly built MooTools build:

$ cat moofx.min.js >> core.js

Moofx has a MooTools adapter, from the README:

Element.implement('animate', function(){
    var moo = moofx(this);
    moo.animate.apply(moo, arguments);
    return this;
});

This code is saved in moofx.mootools-adapter.js, and can be appended to core.js as well:

$ cat moofx.mootools-adapter.js >> core.js

At this point we have all our code we need, and nothing too much. However the MooTools Core Builder on the MooTools website has a compress option. We can do this with several tools like YUI Compressor, UglifyJS or Closure Compiler. It’s outside the scope of this post to explain the exact differences and how you would use them. For now lets just use uglifyjs for our final build step:

$ uglifyjs core.js > core-min.js

No one really likes to do a lot of typing, so you might want to combine the commands in a simple bash script, a Makefile or whatever build system you might be using already. The script in this Gist pulls and builds everything for me.

Beyond Packager

Packager is great for building MooTools Core and MooTools More and many other projects. A great deal of projects on the MooTools Forge are also compatible with Packager. Unfortunately Packager is written in PHP and is actually only compatible with MooTools projects. Since the creation of Packager for MooTools 1.3, the the JavaScript community has (finally) picked up the idea of writing modules and separate components, but has chosen for CommonJS(-like) modules in Node.JS or AMD modules. In my Gist I also use an Packager alternative: WrapUp. WrapUp is a tool like Packager but runs on Node.JS and supports CommonJS-like modules. Writing CommonJS/AMD modules has some sweet advantages which are outside the scope of this post, but you should definitely checkout WrapUp. For now, Packager does a great job by removing unnecessary code and picking the right components. Customize your MooTools builds and get a smaller filesize!

The challenge for this week is to design a turtle drawing program that accepts any form of user input in order to move, rotate and style a “pen” across a canvas. It should resemble the functionality demonstrated in the following diagram…

The important things we are looking for are the ability to change direction and then to move forward in a straight line. You can do this with HTML elements (and some interesting CSS) but we encourage the use of SVG or canvas in your solutions as they are more suited to the task.

Hint: you don’t have to have the labels on the left and you can use text fields (or even keyboard navigation) instead of links. What is important is how you maintain and modify direction and position of the “pen” (the point at the “front” of the line).

You can make your solutions as intricate or as basic as you wish!

As before; post your solutions in the form of links to jsfiddle, tinker or jsbin (in the comment section) and we’ll update this post with a link to a review post detailing solutions that we think tackle the problem in ways worthy of mention.

Good luck!

EDIT [2012/08/15]: We are closing comments and reviewing submissions. We will follow this post up with a review of our favourites and what they teach us about the task and JavaScript development in general.

EDIT [2012/08/22]: We have posted the review post to for these submissions.

Lucas Corbeaux - http://jsfiddle.net/G5RuR/

Code reuse is a big issue when it comes to large-scale systems written in JavaScript. Lucas’ example shows us a method of wrapping processing/private code within a closure to provide a clean API and protected internal code.

Mickele Moriconi - http://jsfiddle.net/THrr6/1/

While not technically JavaScript, Mickele’s example showcases a neat CoffeeScript/Canvas approach to drawing the spiral, complete with text rendering code. If you have never seen or used CoffeeScript Mickele’s example may prove useful in learning some of the basic syntax differences.

Klaas Moerman - http://jsfiddle.net/BNs9z/

Using some clever maths, Klaas’ example shows how the spiral pattern can be generated using a tiny amount of code. While this doesn’t teach us anything specific to JavaScript, the algorithm is still pretty neat!

Cristian Carlesso - http://jsfiddle.net/kentaromiura/KtPw5/2/

Nyan nyan nyan, nyan nyan nyan nyan nyan nyan nyan nyan nyan nyan nyan nyan nyan. Nyan nyan; nyan nyan nyan nyan - “Nyan nyan nyan nyan nyan nyan nyan.”. Nyan nyan nyan nyan nyan nyan nyan.

Tim Wienk - http://jsfiddle.net/timwienk/RQZ7H/

With the advent of Node.JS et al. the JavaScript world has been moving in the direction of Asynchronous Module Definition (AMD) as a means of defining and controlling modules and module dependencies. Tim’s example shows us some of the steps to take in order to create AMD compatible modules of code.

Arian Stolwijk - https://tinker.io/024e3/4

If nothing else, this example’s code is beautifully formatted. It also showcases some neat CSS3-based animation.

Pete - http://jsfiddle.net/tq6Zf/

This guy earns serious points for posting a jQuery solution on a MooTools blog. :)

The purpose of Challenge #1 was to introduce the challenges and exercise your logical brain; using as little “framework” code as possible. We would like to thank everyone that participated - it was fun to see so much conversation and collaboration around a fun JavaScript challenge.

Be sure to check out the Challenges category of blog posts for new challenges every week!

One of the most common requirements of web applications is to be able to respond to user input, and in particular clicks (or touches). Continuing with our theme of element generation (and in some cases animation); this week’s challenge will be to create a basic whac-a-mole game.

The point of the game will be to click on highlighted elements to increase score. This can be as basic or as intricate as you wish it to be, but it should resemble the following diagram…

The green block represents the block a player must click in order to gain points. This means you will need logic to randomly select one of the possible blocks and highlight it. You also need to register user clicks and update the score “label”.

Hint: at times when you need to add many of the same kind of event to a variable amount of elements (in this case blocks); it is helpful and even efficient to use event delegation. You will need to use the setInterval() function or the setTimeout() function to create a predictable amount of time between each click or highlight.

As before; post your solutions in the form of links to jsfiddle, tinker or jsbin (in the comment section) and we’ll update this post with a link to a review post detailing solutions that we think tackle the problem in ways worthy of mention.

EDIT [2012/08/08]: We are closing comments and reviewing submissions. We will follow this post up with a review of our favourites and what they teach us about the task and JavaScript development in general.

EDIT [2012/08/22]: We have posted the review post to for these submissions.

The problem with these kinds of questions is that they often speak of the over-dependence on a certain framework (such as MooTools or jQuery) without a proper understanding of how JavaScript works or how to structure code well.

It is with this in mind that we want to set some challenges in plain old JavaScript (which are probably good programming challenges for any language) that will flex your grey matter.

This week’s challenge is to find an elegant solution to generating elements in a spiral pattern. Consider the following diagram…

Your solution can be procedural or recursive, but in either case you will be dealing with a shrinking grid of possible locations for elements. The colours do not have to be in the result - they are only used to indicate the pattern.

Hint: Try defining variables for columns and rows so that the shape can change but the positioning and order remain the same.

Try also to minimize your use of any one particular set of libraries or modules, but rather use as much vanilla JavaScript in your solution as possible.

Post your solutions in the form of links to jsfiddle, tinker or jsbin (in the comment section) and we’ll update this post with a link to a review post detailing solutions that we think tackle the problem in ways worthy of mention.

We hope to make it a weekly thing, so be on the lookout for more challenges to follow!

EDIT [2012/08/01]: We are closing comments and reviewing submissions. We will follow this post up with a review of our favourites and what they teach us about the task and JavaScript development in general.

EDIT [2012/08/08]: We have posted the review post to for these submissions.

A great deal of thanks goes to Mient-jan, who started working on a fix right away, which was finished a few days ago. Another big thanks goes to Darren for creating an easy to install clone of our Forge, actually making it possible for people to help and collaborate.

We used this weekend to do some testing, and earlier today we activated the changes on the live server: GitHub and the Forge are friends again! We hope the problems haven’t caused too much inconvenience, and we hope that you’ll enjoy using the Forge again.