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/)