Got an email from Xavier Lecomte this morning that his MooTools book is now available. In French. As my French is terrible I’m a poor judge of it’s quality, but Xavier has been emailing me questions and details over the past several months and seems like a bright guy. If French is your native tongue and you’ve been waiting for some MooTools knowledge, I’d say this is worth checking out. Here’s an excerpt if you care to peruse it.
Archive for the ‘3rd Party Libraries’ Category
MooTools pour le français
June 19th, 2012 by Aaron N.A Portable MooTools Development Environment
September 23rd, 2010 by Aaron N.The actual process of developing MooTools itself isn’t trivial. It’s not rocket science, but maybe there is a little alchemy involved. For instance, let’s say you want to fix a bug in MooTools More. You fork the library and make the change to fix the bug and now you want to test it. You need MooTools Core for this, but which version? Looking at MooTools Core on Github you see there’s a branch called 1.2x and also a branch called master, not to mention a tag for 1.2.5. MooTools More has several branches, too; there’s master, develop, 1.3wip and others. Which combination of these two libraries work together?
Then you see some test files in the library. Some HTML files that appear to be demos, but they don’t run on their own. You need to install the MooTools Test Runner to view them (you can see an example of it running at review.mootools.net:9876). And then there’s an external specs runner.
If you decide you want to play with MooTools ART you have similar issues, not to mention the widget library – art-widgets – built on top of it.
While it’s true that jsFiddle gives you a sandbox with a lot of these things, it doesn’t give you a working development environment. In an effort to make it easier to share these configurations, I’ve created a portable development environment that makes it relatively easy to get things up and running.
http://github.com/anutron/mootools-development
I’ve made a github repo that has essentially no code and only submodules pointing to all the stuff I use in states that work. In theory, it should make it really easy to reproduce a development environment from scratch. Eventually I’ll configure several different environments. 1.3, 1.2, 1.1, 2.0, whatever.
Right now there are three environments configured. 1.2.5-art-widgets (which includes everything you need to play with art-widgets), 1.3-art-widgets which lets you do the same against MooTools 1.3 (there are some issues that we’re working on so it doesn’t look great at the moment), and 1.2x-tracking-core-more, which includes just mootools-core and mootools-more on their respective 1.2x branches. These are my personal environments and you can use them if you like.
Note that instead of submodules I’m using crepo. One of the reasons is it will allow us to create a version that’s tracking against a branch. For example, the 1.2x-tracking-core-more branch is always tracked against core/master and more/develop. Typing “./go sync” will update to the latest of these two branches.
The result of this means that we can create specific, deployable environments for others and for each other. I could file a lighthouse ticket against -core with a specific state that illustrates a bug in core/1.3 that manifests itself only in art.widgets (which I’ve done – art.sheet is broken in 1.3).
Note that you don’t have to use django to use the environment. My environment includes the test runner that I wrote and depender. But you can just do ./go sync and get all the repos without building the django app.
This doesn’t have to be specific to MooTools, but that’s what I made it for. I don’t see people trying to incorporate this into other tools, though crepo is designed for that purpose (we us it throughout cloudera).
Book Report: MooTools 1.2 Beginner’s Guide
February 20th, 2010 by Aaron N.I’ve written a lot about MooTools over the last several years, the mootorial, my own book, not to mention all the posts here and loads of documentation. So you might think that I’d look at another MooTools book on the market as competition but you’d be wrong. I love that there are other people out there who want to help others learn MooTools. Writing tutorials and books is just as valuable to the framework’s growth as writing code. In the last year there have been a lot of new materials on that front now that I think about it. Ryan Florence has dedicated his blog to the topic. Mark Obcena has written a whole series called “Up the Moo Herd” that covers a lot of tips and tricks and best practices. Not to mention all the great work David Walsh continues to do (for instance, his recent post on NetTuts – “Make your MooTools Code Shorter, Faster, and Stronger” - was terrific).
So yeah, another MooTools Book? AWESOME. Read the rest of this entry »
MooTools 1.1 > 1.2 Upgrade Helper
December 31st, 2009 by Aaron N.Several weeks ago I had the pleasure of addressing a large crowd of Joomla developers at their conference in New York. The Joomla community is a fantastic bunch and the time I spent there talking about MooTools was perhaps some of the best I’ve had. The people present were very interested in MooTools and as well they should be. Joomla ships with MooTools built in and there is a large community of Joomla plugin developers who end up using MooTools because of it. Unfortunately, it still ships with 1.1.
A few months ago we, the MooTools team, decided to start focusing more on helping the Joomla community with their upgrade woes and began to re-address the compatibility code for 1.1 to 1.2 in earnest. When I spoke in New York to the Joomla team there and said that our goal was to have something to help them upgrade available by the end of the year, there was, dare I say, rawkus applause.
Well, here it is, Dec 31, and I’ve kept my promise. With the help of many of the MooTools Dev team (Chris Pojer, Darren Waddell, Nathan White, and others) we’ve finally got a compatibility layer that actually works and, more importantly, helpes you upgrade.
First, it logs warnings to the console (such as Firebug) and helps you find the places in your code that need updating. The script is not a compatibility layer as much as it is an upgrade helper. Hopefully this will help us retire 1.1 for good.
Secondly, easily half of the work, if not more, was spent creating a test environment for it. When MooTools 1.1 came out, we didn’t have a test framework to run against the code. When we released MooTools 1.2, we did, and it shipped with tests for most of the functionality included. So to make this compatibility layer, we had to go write tests for all of 1.1 (about 400 individual tests), then write the upgrade helper, compatibility code, and then run the tests from 1.1 against the 1.2 code base with the upgrade helper loaded. Creating the tests for a deprecated code base is no fun but I’m glad we did, otherwise the compatibility code would be in far worse shape.
But as a result of all that work by the MooTools Dev team, I can say that the helper script we released today is likely to cover about 95% of all the changes between 1.1 and 1.2; the other 5% being essentially un-hackable. Still, for most developers, it should cover all their work.
Seeing 2010 roll in with people dropping 1.1 is a great way to start it. If you’re still running 1.1, now is the time to move on.
You can find out more about the upgrade helper on the MooTools Blog.
The MooTools Plugin Forge
December 10th, 2009 by Aaron N.For those of you who didn’t notice, MooTools released it’s long vaunted user generated plugin system today – The MooTools Forge [accompanying blog post].
First, this is just awesome news, and a big tip-o-the-hat to Guillermo Rauch, who wrote the app. For those of you who have been around our community for the last three years, the forge was always something we were “working on”. There have been many versions created over the last few years, and many other community created initiatives, that didn’t quite do what we wanted. Guillermo jumped in and built a great system, closely integrated with git, that, well, it kicks ass.
The Clientcide Libs
I’ve uploaded four plugins to the forge as part of the launch (Tabswapper, MenuSlider, HoverGroup, and dbug). I chose these because they were just the simplest plugins that I could release; they just don’t depend on much and they do one thing. Releasing Stickywin, for example, represents a much greater challenge.
One of the things the forge requires is individual git repositories for each plugin. This means that I have to split up my one big repo into lots of little ones, rewriting my download builder, docs engine, and other tools to make these things easy to manage. Consequently, moving things into the forge is likely to be a long and laborious task. For the moment, the four plugins I’ve released are just duplicate files of what’s in the single Clientcide repo, but eventually, once I’ve split them all up, I’ll remove all the files from the Clientcide repo and then include them all as submodules. For the time being, they will be duplicates, and releasing them will happen as I have time (which is not very much these days).
Good Times
I’m really excited about MooTools here at the end of 2009. I hope to make a longer post here looking back at all we’ve done this year, but certainly the Forge release will be a big highlight. 2010 has a lot of interesting things coming, I’m sure, but perhaps the thing I’m excited most to see is all the good things that the MooTools community creates and uploads to the Forge.
MooTools 1.2.4, Clientcide Libs, and What I’ve Been Up To
October 19th, 2009 by Aaron N.I know what you’re thinking. It’s been 3 months since I last posted. My last post was all about how you can pay it back to MooTools, and since then I’ve been taking my own medicine.
MooTools 1.2.4 released today along with MooTools More 1.2.4.1. In this release, I’ve pushed 274 commits into the codebase (out of 398). There’s a LOT of new features in it, but some should look familiar.
For instance, my Waiter class is there, now called Spinner. And my Modalizer class is there, now called Mask. Oh, and Fupdate finally got a decent name; it’s Form.Request.
But there’s a lot of other stuff in there, and that’s not even the only place I’ve been cranking. There’s also a dependency loader for lazy loading MooTools scripts called Depender. There’s an all-JavaScript version and a server side implementation (that’s way faster; available as PHP or Python/Django).
And then there’s MooTools ART, which is awesome. It’s the beginning of a UI system for MooTools plugins.
Rather than go over all this stuff in detail though, I’ll just point you to the blog post I wrote over on the Cloudera Blog, which outlines all the cool stuff we’ve been building with all these new toys. There’s even a fancy screencast.
The Clientcide Libs and MooTools 1.2.4
But you’re probably asking yourself, what about the Clientcide plugins? Well, obviously I haven’t forgotten about them. First and foremost, it should be rather obvious by now that much of my work is now being pushed into MooTools instead of released here. It makes sense mostly, as the plugins get reviewed by the other MooTools dev team members and the result is always better. There are still a few plugins here that don’t belong in MooTools More and to that end I’ve been maintaining them, occasionally adding features.
The current version of Clientcide – 2.1.0 – should work fine with 1.2.4. The catch is that the upgrade path to switch to the new instances of the things that moved (for instance, Waiter moving to MooTools More and now being called Spinner), isn’t super duper easy. I do plan on authoring compat layers for some of these scripts, but not all of them.
What does this mean if you’re using these libraries? Well, you can keep using them. But I’m not going to maintain Waiter, for instance. I’ll focus on Spinner. Converting from one to the other should be relatively straight forward, but since they both work in the same space (because they have different names), you should be able to use either one or both.
Look for a release in a week or so of the next version of Clientcide for MooTools 1.2.4. There are several bug fixes and I will have some compatibility layers for some of the plugins. In the mean time, you should be able to update to 1.2.4 without any issues.
The Exceptions
The only exception here is that MooToosl More 1.2.4 includes a few plugins that are almost direct copies of what I have in 2.1.0, namely HtmlTable and Element.Delegation. If you’re using either of these scripts, you can just ditch the copy you get from me and use the ones in 1.2.4.
jQuery vs MooTools, MooTools vs jQuery
May 18th, 2009 by Aaron N.Every day on twitter I see posts where people are asking themselves the same question: MooTools or jQuery? This is because I have a saved search for “mootools.” Doing a search for “dojo” or “prototype” would find similar tweets from people considering those frameworks or jQuery. The fact is, jQuery is incredibly popular and it’s own popularity breeds adoption as much as the fact that it’s a good bit of software.
Focusing on the “MooTools or jQuery” question, it’s clear that there isn’t a great resource that helps people decide. Looking at the documentation and examples for the two libraries shows they share a lot of functionality. If you’re just now, in 2009, trying to decide which one of these frameworks you want to dive into first, chances are you’re probably relatively new to JavaScript itself and the prospect of comparing the frameworks by actually reading their source code is perhaps more effort than you want to spend. Were I in such a position, I’d want someone to do that for me; to look at them and tell me why some choose one over the other.
So, today I’m releasing jQuery vs MooTools which aims to do just that. No doubt this will cause a stir in our communities but hopefully it will be a healthy one.
I’m not trying to convince people who love jQuery that they’re wrong and should switch, nor am I trying to illustrate to the MooTools community what they’re missing from jQuery. This site is aimed at people who are trying to make this decision and is meant to be an honest comparison of the two libraries. It’s obvious where my bias lays – I’m a MooTools supporter. But I’ve tried to represent the two libraries fairly and, where my opinion is expressed, I try and call that out and say it’s just that – my opinion.
It’s entirely likely that I’ve misrepresented something about the jQuery core library in this post but I’ve done my best not to. Before publishing this site I consulted numerous other contributors to our community. I’ve shared the comparison with authors of other frameworks, bloggers who don’t endorse any particular framework over another, and even sent it to one of the jQuery team members. As I receive feedback, I’ll update the site to incorporate the perspectives of others that may be helpful for the target audience of the comparison (i.e. people considering the two frameworks).
I encourage you to leave comments on the site itself and not here on clientcide.
read on: jQuery vs MooTools
Follow MooTools on Twitter
May 15th, 2009 by Aaron N.I used to make a habbit of posting links to all the fun and interesting MooTools news and whatnot here. I’ve recently been focused on the second edition of the MooTools book, MooTools More, bugs, and a new job and have had less time to post here than usual.
To make up for this, I and other MooTools developers have been posting things on Twitter on @mootools. If you want to know what’s happening in the MooTools world, this is the place to follow. If you don’t use Twitter, you can still get the RSS of the feed.
You can also follow MooTools developers who often post useful things about MooTools that don’t make it on to @mootools (in no particular order):
- Valerio Proietti – @kamicane
- Aaron Newton (that’s me) – @anutron
- Thomas Aylott – @subtleGradient
- Guillermo Rauch – @rauchg
- Christoph Pojer – @cpojer
- Jan Kassens – @kassens
- David Walsh – @davidwalshblog
- Michelle Steigerwalt – @Yuffster
You can find more links for these developers (home pages, github profiles, etc) on the MooTools developer page.
As a side note, you can follow Clientcide on Twitter as @clientcide. I’ll note that the only thing posted there are posts to this blog, so if you’re already following Clientcide via email or rss, you won’t see anything new on twitter.
Bring the BSOD to your Web Apps
May 15th, 2009 by Aaron N.MooTools developer Guillermo Rauch (http://devthought.com) has an awesome MooTools plugin that I just have to share: BSOD.js. Good god, it’s brilliant.
The script BSOD.js provides an easy-to-use class to boost the error reporting user experience of your websites.
Advantages for the user:
Hilarious! The demos are every bit as awesome as the original BSOD.
FancyUpload 3.0 Released
April 30th, 2009 by Aaron N.Harald Kirshner (a.k.a. digitarald) released the latest incarnation of his (awesome) flash / js based file uploader, FancyUpload.
Despite the delay, the completely rewritten version ofFancyUpload, version 3.0, got pushed to github today. This new version is more stable, has betterdocumentation and more showcases than ever. I even added two download packages with runnable installations, like many developers requested. This article introduces the new features and showcases, impatient readers can jump directly to the comprehensive project page or fork on github.
New Features
There are a lot of new features and fixed bugs in this new release, so let me distill the most important ones for you:
- The API with, separated uploader and file classes, allows an easy implementation in all kind of interfaces
- Events are dispatched for every step of the uploading process, to keep the interface as responsive as possible
- Progress tracks the loaded size, upload-rate, estimated time and other values for every file and for the batch as a whole
- File uploads can be stopped, restarted or removed anytime
- New Iframe-based class for multiple, asynchronous uploads without dependency on Flash
- Compatible with Flash 9 and 10 with the browse button as a transparent overlay or as an interactive image sprite
- Ability to change the upload URL and add POST/GET data on runtime, customized for every file or the whole process