Great timing is essential to great interviews (cough) but this one really is a cracker. Mark Obcena only had the official announcement / release of his new book “Pro JavaScript with MooTools” earlier today (after great anticipation, if I may add).
So, what better time to get a few answers from the man of the moment than right now? I present to you the “Dr. Keeto” intermoo. Brush up on your “keetology” and start reading!
Nickname: Keeto
Country: Philippines
Age: 23
Blog: http://www.keetology.com/
Twitter: @keeto
GitHub: http://github.com/keeto/
Famous for: Up The Moo herd series, Pro Javascript with MooTools book
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.
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.
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.
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.
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.
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.
– 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.
Thank you for your time!
P.S. Now that the book is hot off the press, I should mention Keeto is available to pester with _interesting_ problems on IRC (just like most other teams in the MooTools community) – freenode.net #mootools. Go and say “hi” and say Dimitar sent you 🙂
[…] This post was mentioned on Twitter by K.J Ye and KPABA, Dimitar Christoff. Dimitar Christoff said: My @keeto interview is now out – http://bit.ly/gL3qsJ – read about his new book http://amzn.to/e8SpAH and love for #mootools and #javascript […]