The first thing you need to know about my “computing background” is that I went to college for Jazz Guitar. At roughly the same time the web was being born. I was always into computers; building them and playing games and making art with them. When the web first showed up I started fiddling with HTML and making galleries of my photography (which I also studied in high school and college). I took some graphic design courses and helped design, build, and maintain the web site for my school. In 1997 I got a call from a friend to come to California and work on a startup as an interface designer which pretty much killed my music career.

I started my own company in 1999, a music site called Epitonic. It kinda died when the rest of the web did. I joined CNET as a product manager and built more music oriented sites there but slowly moved into technical product management focused on internal projects. At some point I hacked together some prototypes for the network and was annoyed at the lack of JavaScript infrastructure.

I took it on myself to research all the budding frameworks, pick one, and standardize the whole company around it. I started w/ Prototype and Moo.fx but when MooTools came out I quickly latched onto it. I started blogging all this, originally as an internal blog for CNET developers but later as a public blog where we started releasing all the things I was putting together. If you feel like it, you can read my initial impressions of MooTools in this post and a followup that I posted shortly after that.

Since then I’ve been active in the MooTools developer community non-stop. I left CNET and did another startup on my own (www.iminta.com) and then in 2009 I joined Cloudera as employee number 10. Cloudera now has six front-end developers (including Thomas Aylott ed: “SubtleGradient” of mootools-core and Slick teams), all cranking out MooTools code.

Well, lately, I don’t. I haven’t posted much to Clientcide in roughly two years. I have a lot of code on my github account that I want to release but I don’t have time to write docs and promote it. Some of my latest work is perhaps the most interesting I’ve ever done. The Clientcide libraries still haven’t seen a release against MooTools 1.3, though the work is done in github. MooTools More now has 4 other developers on the team and they are responsible for most of the new features and work you see there. So, in short, though I remain active on the mailing lists and I do author a large amount of JS, my contributions this last year or so have been rather thin as Cloudera continues to require nearly all my attention.

But, that said, in general over the years I’ve made it a priority to make the framework easier to learn, adopt, and use out of self-interest. I genuinely enjoy teaching and helping others, but I do these things for MooTools because I want to see the framework succeed. Where others on the team focus on code quality and features, I’ve focused on stability, documentation, tutorials, message boards, etc. because I want to write MooTools code where I work and if no one is adopting it then there’s no market for it. Already you can see that jQuery, which is a fine library for it’s scope, is the defacto standard in much of the market. This makes it harder for people who see the value of MooTools to find work using the framework. Much of my time is dedicated towards adoption to ensure that the project is healthy and can not only survive, say, Valerio getting hit by a bus, but also allow me and you and others to continue working on MooTools in our day jobs.

I mentioned some of this already, but my somewhat self-appointed task at CNET was to create a common JS story for the network. I was a product manager there and every time I’d ask for some aspect of my product to be interactive I’d get blank stares from all the Java guys on my development team. I’d often end up writing the JS for my product myself. After a while I could see that the problem was only going to get worse as the web got more sophisticated; if CNET didn’t adapt our customers would find a site that just felt out of date.

Initially I chose Prototype. I researched a bunch of frameworks and I liked Prototype’s model a lot. But the library was really verbose (it was like, 70K in those days) and it didn’t have element enhancements nor effects; for those you needed Scriptaculous – another 70K or so. Moo.fx came out and it was 3K (!). I started building on top of that and then MooTools itself followed. I loved the framework from the start, but it was not even a 1.0 release yet (r87); there weren’t even docs for it. I knew I couldn’t get the CNET engineers to even consider it without those things, so my first contribution was the documentation. I authored these by reading through the entire source and documenting each method. That single week’s worth taught me more about JavaScript than anything before or since.

While working at CNET I decided to release everything I could. At the same time, I continued to contribute to MooTools Core. Most of my contributions to Core were added because I needed stuff in my actual work. $merge for example didn’t exist in r82. I wrote the first implementation of it (which Valerio immediately rewrote). This was the pattern for a long time; I’d work on my stuff for my job while Valerio and others worked on Core. When I found
something wanting, I’d push it up into Core when I could. As I released more and more stuff on Clientcide it became harder to maintain that code and still contribute to Core in any meaningful way.

About two years ago the MooTools development community decided, at my urging, to focus on growth. Specifically to work to increase the number of people contributing to the framework. The dev mailing list went from something like 12 to maybe around 70 today. About that time we decided to pull over a lot of the Clientcide plugins and make them an official MooTools release. If you look at the MooTools More library today there are about 65 plugins (if you exclude all the localization files). About 40 of those came from Clientcide. Nearly all of them have been rewritten by the team (and are much better for it); they certainly aren’t my contributions any more. Clientcide still has about 50 plugins in it (the next version deprecates about 20 of them). All that code is already too much to maintain, so any notion that I might have about contributing to Core goes right out the window. My todo list is already too long.

As for what I would do if I could do anything; if I could just take a week of vacation and work… well, I always have a long laundry list of things that I’m trying to accomplish. I want to improve the test coverage in MooTools More (which is already in pretty good shape thanks to the rest of the More team). I want to implement some automated UI testing with Windmill or Dohbot or something. I have several repos on github that I want to release; the Behavior library in particular. I need to update the Mootorial. Blah blah blah. It’s a long list.

I would say I was an average developer with an average understanding of JavaScript. I wrote a lot of functions but never used inheritance. My work in JS wasn’t very object oriented. I had a cursory understanding of prototypes but not why they were useful. As I stated earlier, reading through the MooTools source code taught me more in one week than anything I’ve ever done. Valerio is a brilliant developer; his work borders on art if you ask me.

What I’ve learned since then is less about being a better coder and more about working with people. I’ve pushed on the MooTools community pretty hard to adopt a lot of the process and principals that I find in my day jobs. Many of the MooTools developers don’t have jobs as full time developers in a community of developers. They are freelancers or are in school. Valerio spends nearly all his time working on MooTools itself. I’ve had a very different experience working in organizations with dozens or even hundreds of developers. There’s a different priority at work there. At Cloudera I’m surrounded by hardcore developers – some of the smartest guys I’ve ever met. We contribute to a lot of other open source projects (mostly Apache projects) and I see the merit in the structure that those projects have. Doug Cutting, creator of Hadoop, Lucene, Nutch and others, works at Cloudera. He’s the chairman of Apache! I’ve picked his brain a lot about what makes Apache projects succeed or fail. I try and bring a lot of that knowledge to the MooTools developer community. I’m not always successful at it, but there are numerous things that we do now that came from my talks with Doug and others.

I’m not a perfectionist. Look at my code on github and compare it to Valerio’s. Valerio and the other MooTools developers will often choose beautiful code over just about anything; usually that’s a good thing. Their dedication to releasing the best code they can possibly produce is what makes MooTools so wonderful to work with. I am not the kind of person that could produce a MooTools even if I had the technical talent.

I’m a pragmatist. I make things that work and that are extensible, reusable, etc. I often find myself redoing what I’ve done before or extending something I’ve done before usually because I had a lack of foresight in my initial API design. It’s what makes me look so productive. I produce a lot of things that work but they certainly aren’t perfect. I don’t even strive for perfection; I strive for flexibility and functional completeness. I’m not afraid to rewrite something a few times.

That programming to patterns talk that I give is based entirely on my own revelations as a developer. I spent many years doing things the hard way. The stuff I do now is taking that pattern thinking even further (for example, the Behavior stuff I’ve mentioned already). But I can point to several things I’ve authored here at Cloudera that are on their 3rd rewrite.

As for MooTools, I can’t imagine being able to author JavaScript this way without it or something very similar. If I didn’t have MooTools, I’d probably write it myself (only worse) just to keep from going back to the way I used to author code.

Credit where it’s due: Valerio authored many of those demos. We actually use ART in our product at Cloudera. We may at some point remove it or at least portions of it; at the scale we are using it it’s a little slow (not MooTools fault but rather that of SVG/VML). We’re pushing the edge a little I guess.

As for release, there are two things here; ART, and the widget framework that happens to use it. ART continues to slowly march towards release, but that’s something you’ll have to ask Valerio about. It’s unofficially a MooTools project; as soon as it’s ready for 1.0 you’ll probably see it on MooTools.net, but certainly not Clientcide.

As for the widget framework, that falls directly into the “on my long list of things to do” category. Will I release it? It’s on github now with demos and stuff. The real question is will I find the time. The more code I release, the more stuff I have to maintain. The value of open source software is that if it’s useful you find others to help you maintain and grow it, but even that takes a time investment. I’d like to think that as Cloudera matures a bit we’ll be able to focus a little more on packaging this stuff up and pushing for others to adopt it…

I have learned not to make predictions about future releases of MooTools the hard way. I wrote a second edition of my book against the 2.0 branch of MooTools. That was about two years ago. Since then we decided to focus on a more iterative approach to releases so much of the 2.0 branch got back-ported to become MooTools 1.3. The work on my book is essentially worthless.

These days I focus on the current release. When Core goes into testing and its API is locked down, that’s when the work on MooTools More gets safe to start. I’ll point out that the rest of the MooTools More team, in particular
Tim Wienk, Arian Stolwijk, and Christoph Pojer, were instrumental in updating More for 1.3. I contributed very little to that effort I’m sad to say. Cloudera has yet to upgrade to 1.3, though I hope to do that soon.

Most of the things I want to change aren’t about the features or organization of the code but rather priorities and the social structure of the project. Writing software is a social challenge as much as anything. I’d like to see the number of committers on the project quadruple. It would make it harder to introduce change in some ways, but it would make the project more resilient. MooTools More went from essentially one full-time committer to five and there are some awesome things in there now that I personally would never have had time to author. If there were 100 people with committer status it would require each of us individually to give up influence but it would be for the best.

As for the web site, I’d like to see it more focused on adoption. The new Demo environment is a good start in that direction. I’d like to see more tutorials and more community engagement. The guys working on the site are awesome, but like me they have other responsibilities to their jobs and families. We can only go as fast as we can donate time.

Sooner or later I want to go back to managing products. I am involved with MooTools because I care about building good products. I want the web projects I work on to be interactive and fun to use. In some ways, I don’t care if I write the code itself. I like doing it, but if I were to do another startup of my own, I’d eventually hire someone else to take over that work and I’d focus on the product design.

Read the source. If it takes you a week or a month, if you can get to a point where you understand how and why MooTools does what it does – every single line and function – your skills will improve. The second thing I’d recommend is getting involved. Write about what you do on your blog. Release some code! Go into Lighthouse and find a bug to fix. Improve the docs. Makes some demos for us!

Oh jeez. Instead of top 5, I’m just going to list some stuff I use a lot.

• jsFiddle obviously; no surprise
• JSLint – I use TextMate and have this integrated to show me errors and warnings when I save a file. It’s a life-saver.
• Git and gitub have both changed my life.
• I love ReCSS (http://david.dojotoolkit.org/recss.html); WTFramework (http://nouincolor.com/wtframework/2.0/) is also pretty cool
• j for command line work is another huge time saver (https://github.com/rupa/j)
• I love visor for the mac (http://visor.binaryage.com/) – my command line is never more than a single keystroke a way
• I regularly visit the Mozilla Developer Center for docs on JS, HTML, CSS (https://developer.mozilla.org/en-US/)

I’m a 24 years old Computer Engineer that used to have my own software start-up, called Solucione. 5 months ago I received a job proposal from Globo.com, the company I’m working on right now. It’s the internet division of one of the biggest media companies in the world. It’s being awesome to work there.

My first contributions started about 2 years ago on lighthouse (here), commenting and creating test cases for tickets. Then I started pushing some code to my Mootools-core and Mootools-more forks and reporting them on lighthouse. The first time my code got merged was an improvement on the isLeapYear function from more’s Date (here). I got really excited when i saw that being merged and, as I was working with it and loved it, I couldn’t stop seeking for something to do for the project.

It’s the framework that fits my needs and philosophy. As it’s all modular and uses it’s Class abstraction on the modules, my code was always better and more extensible than when I used other Javascript libraries (I tried jQuery before). Using Mootools I saw that I could organize my projects better and reuse code easily. Not to mention that when I started studying the code of the frameworks I liked, I really felt in love with Mootools and made it my number one choice

At the moment, I'm working as the Frontend Engineer of Globo.com's main page, and the entertainment page. Can't tell more details, sorry.

At Mootools, I'm one of the developers from the Slick team, which maintains the awesome, super fast selector engine and CSS parser that shipped with Mootools 1.3.

While programing on my free time, I maintain my own open source projects:

• Meio.Mask
• Meio.Autocomplete

I’m mainly a Javascript developer, so I’m involved on some other javascript projects out there, like jQuery that I use on my work. jQuery is a very good tool, is easy to learn and is the number library in use on the web. Of course I prefer Mootools and i’m working on using it at least on the projects I’m working, but it’s not that simple to change the way Javascript is done by a company with 100+ developers.

The 2.0 part of core that is done right now and is being improved is awesome. It includes a better and more reliable implementation of Fx.Morph, reworked and easier to use Request Class, integration of the Element.Dimentions module with the Element.Style module which will simplify the development, builtin event delegation and more!

Besides core, there’s a work in progress demo page by fakedarren, that will decrease even more the time needed for the developers to run the code they need.

An official UI project would be cool too. There are lots of great Mootools UI components out there, but would be nice to see them together, sharing they’re internal architecture. There’s a project heading this way, called mootools-ui, that uses the great A.R.T. SVG/VML abstration library, but it needs a page and documentation.

Hard question. I dunno… really. I really love everything about it, the community, the code, the fun i have while contributing

Maybe i would be doing something related to oil and robotics, as it was what i saw on the university.

Never stop learning, do not stick with the first framework/library you developed with. Check their codes, learn from them and contribute back!
There’s always a way you can contribute:

• Answering questions and giving ideas on the mailing list and IRC;
• Creating tickets and test cases for the existing ones (https://mootools.lighthouseapp.com/dashboard);
• Creating specs for a new feature or an existing one that you think is not well tested (checkout the Specs folder on the project to see examples of specs, they are very easy to do);
• Blogging about Mootools;
• Code/Documentation contributions;
• Telling your friends how awesome Mootools is [:P];
• lots more, etc.

Website – mootools.net. Plugin? Meio.Mask [:P]

1. Mootools.net – http://mootools.net/
2. Ryan Florence’s Blog – http://ryanflorence.com/
3. David Walsh’s Blog – http://davidwalsh.name/
4. Aaron Newton’s Blog – http://www.clientcide.com/
5. Jsfiddle – http://jsfiddle.net/

Visit my blog, it’s a little outdated but there are some great articles out there.

// 1
$$("#someid div.something");
// or 2
document.id("someid").getElements("div.something");

• If the browser has the querySelectorAll method, the Slick Engine will detect it and use it right away, lightning fast
• If the browser does not have it, in short–it will do document.getElementById(‘someid’).getElementsByTagName(‘div’) and for each of the found nodes, it will check for the existence of the class ‘something’.

• For every browser, it will grab the element with id ‘someid’;
• Then, if the browser has querySelectorAll, it will use this method to grab all the divs with the ‘something’ class from the ‘someid’ context;
• if the browser don’t have it will use the getElementsByTagName(‘div’) method from the ‘someid’ context and for each of the found nodes it will check for the existence of the class ‘something’.

So, as seen, first one will be faster for most of the browsers and is recommended.
From the time of this interview Firefox, Safari, Chrome, Opera and IE >= 8, have the querySelectorAll function.

You just gave me an awesome idea for a blog post

I live in Salt Lake City, UT with my wife and two kids (a 3 year-old iPad addict daughter, and a chubby 3 month old boy). I work from home for the bay area creative agency, Clock Four doing mostly front-end development.

My first real job was back in the 90′s cranking out websites as a teenager for a local ISP. I tried to learn C++ in 21 days but couldn’t get past the second chapter. About the time Java applets started popping up on websites the ISP went broke. I had no interest in programming and started selling decals I made at school online (people actually mailed me hand-written checks!)

After college I was in sales, and eventually ended up working as an implementation consultant for PolicyTech, renewing my interest in web development. Dissatisfied with quickbooks on my Mac I decided I’d learn how to write a web application in PHP and JavaScript to handle my invoicing and accounting. I found scriptaculous first, but couldn’t get some animations to quit bumping into each other; then I found MooTools and its genius Fx module. I was still clueless though, mind you.

Shortly after this, MooTools 1.2 came out. The new documentation flipped a switch in my brain or something. Suddenly the concepts of objects and classes made sense. I rewrote my invoicing application as a single page, desktop-esque, ajax heavy, ridiculously awesome tool that I still use today. As I dug deeper into MooTools I accidentally uncovered a pot of golden, vanilla JavaScript knowledge.

Being self-taught, I put a high value on documentation. I wrote MooDocs to document and release my scripts and provide a way for others to share theirs (no forge yet). That site earned me an invitation into the MooTools developers circle and I’ve held the “MooTools FTW” banner ever since.

Oddly enough, MooTools was my first programming “language”. It was my programming university–it taught me to focus on the API, test my code, and program patterns rather than implementations. Now I view everything else with that bias, whether it’s jQuery, Ruby, or Objective-C.

I stick with MooTools for two reasons. First, I love JavaScript. The Type extensions allow me to write clean, natural JavaScript–no screwing around with namespaces and abstractions that hide the language: arr.include(item) versus ns.utils.array.include(arr, item). Second, I love classical inheritance, and object templates. My brain is naturally wired to think that way. The world around me is designed that way–dogs inherit from mammals. The end goal is to reuse code, which I can’t seem to do as well with differential inheritance–which is like, Siamese twins can share the same legs, right?

Moo4q definitely elevated my reputation in the JavaScript community and was a lot of fun to figure out. It’s certainly stable, I’ve used it several times in production (it’s just a custom build of MooTools plus a small Class mutator). The site gets about 100 visits a day, mostly to the tutorial page, so I think there are a few folks actually using it.

As for using it in a serious application, I dunno. From a MooTool’s perspective you’re really just swapping out the Element, Fx and Request modules for jQuery–which doesn’t really offer you anything new or better than what MooTools already has. From a jQuery perspective, you have to learn so much about MooTools’ patterns, you might as well jump all the way in.

So you’re probably asking why it exists. I use it in two cases. 1) I’m stuck with jQuery and need to do something that I’ve already done in MooTools. I’ve found that usually 10% or less of my classes have to be adjusted to become moo4q classes. 2) I’m delivering templates to a client who only knows jQuery. I can still structure my stuff the way I like to, and they can do whatever they want with jQuery after delivery.

Haha, yeah. Originally I had hopes of it being a gateway drug for jQuery users to eventually fully convert. But in the end, moo4q is mostly appealing as moo4-devs-stuck-with-q. I don’t think it hurts MooTools adoption, probably helps by showing outsiders quite plainly what it can do. It also serves as a solid demonstration of the scope difference between the two.

Man, I think I have development ADD. Outside of outlining more articles for my site, I’ve been working on a lot of stuff. SlideShow 2.0 is a few commits away, which brings with it a handful of (awesome) improvements and performance gains, including CSS transitions.


Speaking of which, I just released CSSAnimation, a vanilla JavaScript implementation of CSS transforms and transitions–complete with MooTools and jQuery API extensions. It powers the new transitions in SlideShow.

Two new scripts I’ve been giving a lot of attention to are Channels and Element.Behaviors. Channels is an extended pub-sub pattern that allows you to completely decouple your objects from each other. Element.Behaviors lets you separate your JavaScript from the DOM. The two together have been a lot of fun to work with.


On the SSJS front, CrypticSwarm and I just started porting packager to packager-node. I’ve also recently written an alternative MooTools documentation browser as my first node project that I hope to make a whole lot better now that I’m learning more.

My website is built with nanoc, a static site generator built with Ruby. It’s surprisingly powerful, and has sped up my development process at work for building micro-sites and similar projects. Haven’t had the time to give back to the project, but I have some stuff I’d like to contribute.

Core – MooTools Core has had the same API for 2 years (!), it was done right. But I’d love an ES5 shim with no dependencies and more modularity with the Type extensions. There’s a lot of those extensions in Core that are rarely used (string.hyphenate?). At least $chk is gone, which was useful for allowing 0.

UI – I’d love to have a UI library comparable to Dojo dijit.

Website – I think a node version of the forge will get a lot more interest and contributions from the community and packager support would be awesome. Also, I’ve been promising Darren my time to write a whole boat load demos to help the sorry demos page out.

I’d still be flying around the country consulting people on how to manage their policies and procedures, making a whole lot less money. I owe just about everything about my current employment to the MooTools community. David Walsh is responsible for 50% of my twitter followers and website visitors, and is always a great sounding board for APIs I’m trying to develop for my plugins. I’ve learned almost everything I know about web development from everybody who hangs out in IRC (and Aaron Newton, who doesn’t). I owe a special thanks to Thomas Aylott, who got me my current job and has helped me understand JavaScript and web development more than he probably realizes. So yeah, without MooTools, I probably wouldn’t be a developer at all.

Dimitar: Yes, I need to get SubtleGradient to say a few words here too…

jQuery will remain #1. Like I said on twitter a while ago, most everything about jQuery is an implementation, making it ridiculously easy to learn. Even with the recent rebirth of JavaScript, most people making websites still don’t know, or care to know, the language. For them, jQuery is the obvious choice, and rightly so.

However, people are writing more JavaScript than ever and need more than just a DOM library. Alex Sexton has an awesome talk called jQuery’s best friends. He’s a smart, influential guy. I think his approach to pull in other tools outside of the jQuery scope is totally appropriate. We are already seeing the advanced jQuery users adopt this strategy.

On the flip side, you’ve got bright developers like Rebecca Murphey turning away from jQuery for their bigger projects. When jQuery users start feeling that “holy crap, what have I done?” feeling with their JavaScript, Dojo is the natural place to go. Just search and replace $ to dojo and you’re more than half way there. Nearly every jQuery method has a Dojo cognate. Also, both hang everything from a namespace. This makes it an easier transition than jQuery to MooTools. Add to that its incredible UI library and support and I’m quite sure Dojo will become the top library for non-trivial websites, if it isn’t already.


So what about MooTools? MooTools doesn’t seem to care a whole lot about adoption (look at our demos page), so I don’t see us making any sort of huge leap in market share. It’s a completely different paradigm. When all the books freak people out about extending the prototypes of Array and String, etc. or that “JavaScript doesn’t have classes” it adds a level of FUD that some just can’t get over. I do think, however, that our user base will continue to grow with really talented people.

Good question. Developers switch projects, contracts, and companies so often my motivation is mostly for the person stuck with my code a year from now, which boils down to support and documentation. MooTools is of course my default choice so I tend to ask myself these questions to justify not using it.

Who is going to maintain this code?

I write a lot of front-end templates for clients to implement into their CMS (or whatever). Once delivered, I’ll probably never see it again. Most of the time the client’s developers have little JavaScript experience outside of jQuery, so I use jQuery in these situations. If there are some really sophisticated specs, however, I’ll push the client to use MooTools, or just slip moo4q in the back door.

Do I need a UI library?

One word: dijit. It’s a part of the Dojo toolkit, well documented, and therefore likely to be supported well into the future. Everybody ought to spend an afternoon playing with Dojo dijit.

jQuery UI has a miserable API, so I’d never choose it.
MooTools doesn’t have an official UI library so you’re on your own to write and document an API, or you have to rely on plugins that may or may not have good support and documentation now or in the future. If it’s a personal project, however, MooTools, regardless.

Which browsers are supported?

Occasionally I get to work on something that only has to work in the newest browsers. In these cases I shed all the libraries and go commando with vanilla JavaScript.

What does the client dictate?

Sometimes I have to use jQuery, even if another choice would be better, because the client says so (ASP.NET, cough, shipswithit, cough). It’s not worth the fight and I like getting paid

Actually, I wouldn’t say “learn JavaScript.” When you learn MooTools, one day you’ll wake up and realize you’ve learned JavaScript.

That aside, I think my single tip would be read the source to the plugins in Core, More and the Forge (Core has some crazy JavaScript, but Fx.Tween is easy to understand). When you’re writing something that feels similar to something else, go read the source, see how they did it.

Website – jsFiddle. Plugin – SlideShow. I know it’s my own, but it is so useful for content that shares the same space (not just slideshows) I often forget that I wrote it.

1. Google
2. Your editor’s documentation
3. People, mentors, mailing lists, IRC
4. Modernizr
5. Early morning hacking–your mind solves the problems in your sleep, dead serious

We just launched a new site for Capital One, advertising their student credit card, Journey. I had some extra time so I screwed around with 3D transforms and CSS transitions on the credit-101 page (safari only). It’s this project that led to Element.Behaviors and CSSAnimation.

No, not me, although I did create this. All of my code is pretty much beginner’s luck, which is not the way of the ninja.

I’m a software developer and graphic designer from Manila, Philippines.

MooTools has always been my framework of choice, but I actually got involved with the community later than most of the early adopters. It was mid-2008 when I started hanging out in the official IRC channels, and that was mostly an accident. I was doing early contributions to Appcelerator Titanium back then, and I had the idea of porting Snippely (an old MooTools project from Valerio and Tom) to Titanium. So I went to the IRC channel to ask for permission to port.

Around the same time as my appearance, Jan was working on a project called Fire, which was a MooTools extension framework for Adobe Air. Since I had some experience with Adobe Air, Jan asked me if I would like to contribute to the project, to which I agreed. We worked on the project for a few weeks but we abandoned it at the end due to being too busy with other stuff. However, the project forced me to be constantly online in the channels, and I’ve never been away for more than a few days since then.

Eventually, I got the idea of writing a series of advance MooTools articles for my blog, and that eventually became the Up the MooTools Herd series which really started my community work.

There are two kinds of JavaScript frameworks available today: those that rely on abstraction and those that rely on extension. Frameworks that rely on abstraction are very easy to spot, since they produce code that look nothing like native JavaScript. They stick out like a Java class declaration in the middle of an Erlang source file. Extension frameworks, on the other hand, are subtle; they blend in with the language and appear like part of the standard library.

MooTools is one of those frameworks that fall into the extension category. I really don’t see MooTools as a framework but rather as an extension to the language itself. MooTools is to JavaScript what Objective-C is to C: it’s not a new language per se, but a thin layer that adds features to the language itself. The fact that it implements both a Type and a Class system–both language level features–is a testament to this extension nature of MooTools.

This difference between abstraction-based and extension-based frameworks is important for people who actually love the languages they use. The more you like a language, the more you’ll tend to lean towards frameworks that magnify rather than mask it. You’ll want to work more closely with the language in terms of syntax and philosophy–and burying it under heavy (and often leaky) abstractions would simply be daft.

I’m working on a lot of stuff, most of them related to MooTools and CommonJS. Perhaps the most exciting of them is Meso, which is a cross-engine MooTools library for CommonJS. Another thing that’s keeping me busy is Deck, which is an HTTP Server layer that runs on top of Meso.

I’m quite involved in a lot of things, at varying extents. I used to be very active with Appcelerator’s Titanium platform, but my involvement tappered off a bit because of work. I’m also experimenting a lot with Apache’s CouchDB and Steve Dekorte’s VertexDB, and I plan on hacking the latter in the coming weeks for a project I’m building. And of course there are my own projects that I’m working on together with other MooTools devs.

Depending on when this interview is published, the book would either be coming out in a few days or has already been released. I’m quite happy with it, although I would really like to expand some chapters in the future. Print publishing places very big constraints when it comes to writing time and publishing dates, and that really affected the book. I do think it turned out good, although–like many authors–I do believe that there is a big room for improvement.

Whether or not “less advanced” MooTools users will benefit from reading the book is totally up to them. After all, the MooTools source code has been open-source from the start, and there’s nothing about MooTools in this book that you won’t learn just by reading and examing the source code. If someone really wants to learn MooTools from the inside, all they have to do is look through the source code–they don’t need my book.

It’s also not my intention to promote coding standards and best practices in this book, since it’s not a book about how to develop with MooTools. It’s a JavaScript book that examines MooTools internals to help people understand what’s going on inside the framework. The goal then is to give people a starting point in exploring the capabilities of MooTools. How they apply what they learn from the book is totally up to them.

I believe that things are just gonna get better. Even though HTML5 is uttered like a buzzword these days, the attention its been getting represents a very real acceptance of the technology from the people–not just from the web community. It’s reflective of the excitement everyone has for a better web ecosystem.

JavaScript will remain the de facto language of the web. You might think that I’m happy about this, since I like JavaScript, but it also saddens me a bit. I do want to see something like Native Client to succeed, if only to add some healthy competition on the client-side. But I don’t think that this will happen any time soon, as most browser vendors have disregarded the technology–explicitly and implicitly by not commenting on it.

Server-side JavaScript will continue to grow, but it won’t take over anything. In as much as we JavaScript people would love to think that SSJS would conquer the whole of the server-side, the truth is there are already a lot of established languages that have been offering what SSJS is selling–and a lot of them are way better at this. Fans of the popular SSJS engines like to think that they’re using something novel, but most of the ideas that these new engines are touting are simply JavaScript rehashes of things already included (by default or by extension) in other languages. JavaScript is only playing catch-up.

One advantage of SSJS, though, is the fact that JavaScript reigns supreme (for now) on the client-side, and it’s the only language that can actually claim to be *realistically* usable for both the client-side and server-side. This is why I support CommonJS as a whole rather than individual engines, because CommonJS represents an ideal rather than a solid API. Getting bound to a new-fangled engine’s APIs is dangerous once the hype dies down.

For MooTools Core, I’d personally want to see it split up into two main projects: one for ECMAScript and one for JavaScript. This is needed if MooTools branches out into the CommonJS space in the future, since CommonJS by default is more concerned about the ECMAScript rather than the JavaScript part.

I’d also like to see some additional metaprogramming APIs for Core. The biggest strength of MooTools is its extensibility, and I’d love to see some of the internals exposed via safe APIs. This will benefit those who’d like to extend MooTools without touching Core.

I’d probably be running around the office right now looking for my editor to get him to approve my story for next morning’s paper.

There are a lot of factors, really. For one, it still depends on the people. As more and more developers start building more complex applications, the bigger the need is to use the proper tools for the job. MooTools is a very good framework to work with, since it can actually scale pretty well–but even that depends on the person using it. Not everyone who touches a paint produces a Picasso.

And even if people start flocking towards better frameworks, it does not mean that they’ll automatically choose MooTools. MooTools is awesome, but it’s not the only awesome framework. There are other scalable and well designed JavaScript frameworks competing in the space, and MooTools is simply one of the choices.

Be a scientist. The developers I respect and admire the most are those who always feed their curiosity, are always hungry for new information and are always exploring. They don’t sit around and wait for someone to answer their questions; they find out the answers for themselves. They experiment, they observe, and they share their results to the world.

The official one.

- Google (with proper search keywords).
- Reddit and Hacker News, or basically any site that aggregates a lot of stuff.
- The documentation for the technologies you use, and their source code.
- The documentation for your text editor.
- Your creativity.

All my public code are available on Github (http://github.com/keeto/)

I am 21 years old and I live in the wonderful city of Graz in Austria. I am a student of Software Engineering and Business Administration at the Graz University of Technology. I would define myself as (Mobile) Web (Application) Developer and I am active on the Internet for as long as I have a connection – that’s about ten years now!

When I started with web development I started using JavaScript. I didn’t learn the language at first but when JavaScript and XHR got more widespread adoption later in 2005 I started building my own little animation library. Shortly after I found moo.fx and I became a frequent reader of the mad4milk blog – the place where “moo.dom” and “moo.ajax” were released which eventually lead to MooTools. I was a MooTools user since the famous 0.87 version and I remember bugging Valerio to include “DOMReady” back in the days. I stuck around and got to know the core developers but only a few years later I started to actively contribute and eventually I became a member of the Core Development Team.

The module that got me using MooTools was Class.js. Back in the days we didn’t even have inheritance or mixins but given that I was unaware of the prototype-based nature of JavaScript, Class made me feel like home. Ever since, I love how MooTools works, the abstractions and the clean code, just great. However, at the moment, the most important part about it is our community. I actually got to know and got to meet a lot of the MooTools developers and they have all become great friends.

Right now I am doing lots of probability theory, object oriented analysis, data structures and algorithms, software architecture and information security related stuff. That, of course, doesn’t have anything to do with MooTools but during the semester I don’t have time for anything else really. But fear not, in the web assignments I am of course making use of MooTools (and PowerTools! ). Recently I did some experiments with DeviceOrientation and DeviceMotion on iOS 4.2 (see http://twitter.com/#!/cpojer/status/7485711225716736).

You can usually find me doing work around the JavaScript eco-system. Therefore I am involved in a number of minor projects, nothing similar to MooTools. I am involved with GitHub. It makes the development experience so much better and more fun – it is easy to contribute to almost anything.

The goal of PowerTools! is not to make MooTools mobile compliant – MooTools works great on mobile devices already. One part of PowerTools! is the mootools-mobile project, which brings custom gestures and more for your mobile web app. PowerTools! is about providing low-level MooTools extensions or HTML5 related plugins that help you speed up the development process or to make your code more maintainable. As far as mobile is concerned, yes – mobile browsers have a lot of catching up to do, but we will get there. The mobile web is definitely important. PowerTools! is currently standalone and there are no plans to officially include it with MooTools. I don’t want to bloat our beloved library

Oh well, there are a lot of buzz-words in there. I honestly have no idea, unless you have time to read five different scenarios on how the future might turn out? Haha, I thought so. Seriously speaking, it’s difficult to say. I think its reasonable to say that the amount of abstractions will increase and a lot of things will get easier even though under the hood they become much more complex. It’s just the beginning. And also, it’s just JavaScript.

MooTools 2.0 of course! The whole thing will blow your mind, once its done of course

Well, that would mean I would not be involved with anything related to the Web. I’d probably just go for a BA masters, but that would be the most boring thing… In any case, without MooTools my life would be very different, not nearly as awesome as it is right now and I wouldn’t have made so many great friends – I am really grateful. Also, the word “Ping!” would not make me laugh, Djamil wouldn’t be a funny person and ketchup would just be ketchup.

**editor** [1] to fully appreciate what he’s saying, you really have to see the MooTools core team eat burgers, chips and ketchup, or rather, have some food with their ketchup. Failing that, you can always login to IRC and “ping” cpojer, he loves it!

The numbers vary, I am not so sure about their correctness. MooTools is being used a lot behind the scenes – in huge internal applications. That is where I see MooTools. If you want to do serious web applications, MooTools is the obvious choice. Given that we are moving to a “Web of Apps”, MooTools has a good starting place. Let’s see where the journey will go.

What I have found is that most Web Developers still do not have an idea of what they are really doing. My advice is to learn the core concepts, learn about how the Web works, learn about object oriented languages, learn JavaScript. If you know the basics it only gets easier and a whole new world opens up every time you learn something new. MooTools can help you hide the complexity behind JavaScript and makes it easier to get started. Also, don’t be afraid to ask questions. It is what I do all the time when I want to learn something. Join the #mootools IRC channel on Freenode and ping me (cpojer), I’m happy to help!

I don’t usually have one. If you want to learn MooTools then go to David Walsh’s (FTW) website http://davidwalsh.name/ – also, the site is awesome for using the hover-effect on links which I created Some people claim David stole them, I refuse to believe that.

GitHub. MooTools.net. PowerTools!. NetBeans. Chrome Web Inspector.

I am a father, an aquarist and a web developer. I enjoy designing and maintaining my never too big “nature style” aquarium. I like watching my children grow and learn. I also like free stuff a lot. That’s why I created jsFiddle and didn’t hesitate too long to join Mozilla Team.

I started programming when I was 19. It was Turbo Pascal on XT’s and AT’s. At university I realised I like Gopher, IRC and FTP. Then in our university library someone placed 3 public computers connected to the new thing called World Wide Web. I was usually not consuming the content, but looking at how it was build. Soon I had my own website…

I was hired by Moving Picture Company to create an intranet tool for movie management. They gave 10 working days to find out the best technology for the front-end. On the back-end Django was set from beginning. I was investigating all possible JavaScript frameworks and MooTools was something which I found the best, although I didn’t know anything about it at day 0.

Classes, clean code, ability to shape things in a way developer wants. I found a lot similarities to Python which is good as I write back-end in this language. I think it’s the best tool for someone who writes code, not only uses plugins.

I’d like to make Accordion better. It is considered as a bad UX, but I can’t imagine jsFiddle without it. I also started to rewrite jsFiddle – beta is coming (we aim for January). There is also another launch coming at Mozilla. We would like to have the Addon Builder 1.0 ready for the Firefox 4.0.

FlightDeck is open-source (as whole Mozilla), otherwise nothing I could call “involved”.

I needed it. I would guess it’s the most honest answer for majority of start-ups. I was on #mootools IRC channel and we were helping new users with JavaScript/MooTools issues. We were even playing who will answer first, but the rule was – code has to fit in one line. Soon there was a question which was longer then that – although we do have pastebin I wanted to check if my idea was right before posting. I thought creating file with right DocType, including files and then loading into the browser was too much trouble. The question remained unanswered, but the next day I had a working prototype.

Just as a side note – jsFiddle wouldn’t be as awesome if not help from Oskar Krawczyk who is the “front-end guy” and other members mostly around MooToos community. Thank you all very much.

Back-end is all Django, MySQL and memcache. It still uses Apache, but I think beta will run from within Nginx or something similar. On the front-end we do use MooTools with a bunch of plugins such as ClientCide. CodeMirror is highlighting the code.

Yes – mooShell will be closed when jsFiddle beta will start. It is currently in read only mode. I am still uncertain what type of license should I use for the new jsFiddle. It is a rewrite… I’d like to make it open source, but the business model I have in mind might be against it.

I think the most awaited is user profile with ability to personalize jsFiddle – change editor application (there is a choice now!), the way it displays code, manage the framework drop down, etc. We will also add PRO accounts with many features around private fiddles.

This is a hard question – it’s mostly the community behind the project. We tried to add every framework which is a “must have”. There are few exceptions (like Processing js or Raphael which aren’t even frameworks), which we simply wanted to use. Beta version will be more specified and with the ability to tweak the “hot list” we will be able to implement much more frameworks. Some will be simply hidden by default. I am also adding the “Framework manager” badge. Users with such privileges will be able to maintain the framework – upload/link new versions, add best plugins, etc. More power for the users.

The way the dependencies and frameworks are bond together is wrong – this is invisible for the end-user, but adding new version of the framework is currently a pain.

On the front-end side – it would be fixing the layout for small touch screen devices.

I had a few other ideas in mind, but these needed much more work on the beginning, which is a pain for free projects – not enough hype.

“Jetpack” is a working name for the new Firefox add-ons type. Firefox 4 will have it build in. It allows to install add-ons without restarting and is really easy to write. CommonJS style. SDK currently uses Python (I think it will use NodeJS in the future) and involves some work to be done to install on the developers computer. Mozilla thought it would be good to make this a lot easier and the idea for Addon Builder aka FlightDeck arised. It could be name jsFiddle for Firefox Addons. Users are able to edit and test addons without leaving the browser.

JavaScript developer to me is a person who writes the code – classes, plugins. The knowledge of vanilla JavaScript is essential. So the tip would be – learn vanilla JavaScript. If I would be able to give another it would be: read framework’s code. It is interesting and enlightening.

Github, documentation sites from framework developers, VIM, IRC, Linux, Twitter. I don’t need much

It would be http://webdev.zalewa.info/. It’s a really old site, half of the examples there are from the time when I thought I could be a web designer, but clearly I’m not made for it. I guess you’ll find quite a few 404 on it as well.

My name is David Walsh and I’m a 27 year old Web Developer living in Madison, WI. I’m a self-taught developer that is obsessed with learning everything there is to know about front-end web development. My expertise is in HTML, CSS, JavaScript, and PHP. I work with jQuery, MooTools, and Dojo on a daily basis. I don’t design the websites, I make them work.

My first exposure to MooTools involved a project that required smoothly animated elements. I found jQuery and its animations where laboring to say the least. MooTools’ animations were as smooth, efficient, and the the syntax was logical. From there I was hooked. I started a blog to share my findings and experimentations. I got better MooTools and started getting noticed by the community. A few commits and dozens of blog posts later, I was asked to join the MooTools team. Joining the MooTools team is one of the proudest moments of my career.

MooTools is special for several reasons. The MooTools API is as coherent and logical as you will find in a framework of any language. The code is as well written as you’ll find. MooTools is modular, efficient, and provides an outstanding inheritance pattern. The MooTools team cares about its community. MooTools isn’t about marketing itself and begging for attention – MooTools is about outstanding code to create dynamic, fast websites. MooTools is magic!

Per the framework itself, I always have two goals: making the community aware of new features and strategies, and creating useful, well-coded plugins to display the power of MooTools. I don’t spend much time on committing to the repository other than quick fixes and documentation updates – my strength is spreading the good word Moo.

I work for SitePen so I occasionally commit quick fixes to the Dojo Toolkit. I write exclusively about open source projects on my blog, and give my code away for free.

I work so hard because I love JavaScript, MooTools, and its community. Let’s face it – we’ve all faced a technical problem that we’ve needed to scour the internet to figure out. Most people find their solution and move on. I’ve vowed not to do that – any solution to a complex problem that I find ends up on my blog so that other people don’t need to suffer the same pain that I did.

Per the MooTools project specifically, I strive so hard because I’m so passionate about the project. I love the codebase, respect the hell out of the developers creating the code, and appreciate the MooTools community. I could write a million blog posts about MooTools and not feel I’ve given as much to the project as its given me. MooTools FTW.

The motive behind writing code to accomplish similar tasks with each framework is to show my readers that, in the end, it’s just JavaScript. Dojo, MooTools, and jQuery are very different but in the end, they’re just an abstraction of JavaScript patterns and APIs. I also do it to show developers the different coding patterns available and the differences in syntax.

What’s important, more so than preferring one framework over another, is find the framework that best fits a project. You can love jQuery but what if it’s not a great match for a specific project? You’d be wasting time using it. In the end though, if all things are equal, I’d use MooTools before any other project. Extendible, compact, logical… those are what MooTools is all about.

The future is looking up! Let’s be honest: the reason we create (and use) CSS and JavaScript frameworks is because the tools we need aren’t available at the present time. HTML5′s markup rules bring us back to a more common-sense approach, and its new JavaScript APIs like WebSocket, classList, and storage APIs are outstanding. V8 and server-side JavaScript are also exciting – imagine writing and entire website, front and back-end, in just JavaScript! MooTools works on both the server and client side which is even more exciting! WebKit-based browsers continue to amaze me – the capabilities they provide, especially with CSS animation, are percolating. Using CSS-driven animations instead of JavaScript animation will lead to faster, smoother interfaces. I’m excited to see what’s next!

I would like to see some of the MooTools 2.0 features incorporated ASAP, including CSS animations and the unified Fx timer. These features have been coded but not implemented so as to not create such a jump in upgrading. There are many other features in the 2.0wip branch that I would love to see implemented. Unfortunately, now is not the best time to release these features due to other API changes that would be required.

I owe much of my career advancement to MooTools. MooTools ignited a fire the fire which made me dedicate my career to JavaScript and front-end development. I’d likely be working at an average Web Development shop, waiting for the clock to hit 5:00.

Like other web technologies, MooTools’s future is nothing but up. Our development team continues to grow, as does our loyal, intelligent community. As far as features I’d like to see, I’d love to see a Dijit (Dojo Toolkit) UI competitor created for MooTools. I’m also hopeful that the Forge continues to grow at its current pace – it’s a treasure chest of great MooTools plugins!

My tip would be this: when you create a plugin/class, take a step back and ask yourself:
`Can I make this class more generic so that it could be used for other purposes?`
If so, create that base class and use MooTools’s Extend/Implements methods to create your more specific class. MooTools is founded on flexibility – learn how to properly use its inheritance methods and you’ll be an unstoppable programming force.

This will sound insanely vain but I have to say my own. I refer to my own website often to grab code I’ve posted in the past. I also get user feedback so I can improve my code. I also love the MooTools Forge – its code holds the value of Fort Knox.

A few people you should really be following if you’re into MooTools, jQuery, or just JavaScript in general:

Ryan Florence (http://ryanflorence.com/) – Ryan’s an outstanding JavaScript developer that writes interesting tutorials about jQuery, MooTools, and CSS animation. He’s the creator of MooTools SlideShow, Moo4q, and MooTools’ pub/sub plugin: Channels.

Kris Zyp (http://twitter.com/kriszyp) – Kris is a Dojo committer, author of the JSON Schema spec, and creator of Persevere, a server-side JSON technology. Kris is a JSON guru, server-side expert, and overall JavaScript nut.

There are a billion more plugins left for me to write! I’m hoping to write a Facebook photo-tagging clone soon, as well as anything else I see that tickles my fancy. Wherever there’s an idea there’s a MooTools plugin to write. There are only two limitations to MooTools plugin creation: inspiration and time. I could write MooTools plugins forever!

I’m not big into self-promotion, but a few of my more popular posts and MooTools plugins include:

• ScrollSpy – A MooTools plugin which monitors scrolling to fire events based on page position.
• LightFace – A Facebook Lightbox clone which handles AJAX, IFrames, Images, and more.

If you want to see what I’m all about, visit my blog: http://davidwalsh.name

‘Ninja’ is a lame term to try to make JavaScript development seem exciting to outsiders. In any event, the boom in JavaScript popularity is nothing but exciting. More bright minds to solve client side problems is a boost to JavaScript development and provides more ideas to the development pool. JavaScript is the future of web development.