049 JSJ MooTools with Valerio Proietti and Arian Stolwijk

by woody2shoes on March 1, 2013

Panel

Discussion

01:08 – Arian Stolwijk Introduction

01:39 – Valerio Proietti Introduction

02:21 – What is MooTools?

07:04 – The Class System

09:36 – Milk

10:25 – Design Goals

  • Ghost

11:19 – Prime

14:18 – MooTools vs jQuery

19:53 – Using MooTools and jQuery together

21:08 – MooTools for Frameworks

23:48 – Chaining

26:59 – Request API for Ajax calls

29:11 – Favorite MooTools-using Websites

29:45 – Accomplishments

31:36 – The history of MooTools

Picks

Next Week

QUnit with Jörn Zaefferer

Transcript

MERRICK:  Yeah, call me Mer-rock, I’m cool with that.

[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]

[This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]

CHUCK:  Hey, everybody and welcome to Episode 49 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames.

JOE:  Howdy.

CHUCK:  We have Merrick Christensen. 

MERRICK:  Hey, guys.

CHUCK:  Jamison Dance.

JAMISON:  Hello friends.

CHUCK:  And I’m Charles Max Wood from DevChat.tv. And I just want to remind you, if you’re going to sign up for Rails Ramp Up, you have one week.

We also have two special guests and that is Valerio Proietti

VALERIO:  Hello.

CHUCK:  And Arian Stolwijk.

ARIAN:  Hello.

CHUCK:  And I think I got close on those names. Okay. So, why don’t we have Arian go first? I’d like you just to introduce yourself really quickly for people who aren’t familiar with who you are?

ARIAN:  So, I’m Arian. I’m a MooTools developer mostly. Besides that, I work for a company called Symbaloo which is bookmark website page. Besides that, I’m actually still studying for my Master’s Degree in Embedded Systems. And that’s about it.

CHUCK:  Cool. And Valerio, do you want to introduce yourself?

VALERIO:  Sure. Well, I created MooTools a few years ago and since then, a lot of cool people have joined the project like Arian who we have here today. I’m currently working in Sweden at Spotify.

CHUCK:  Oh, cool!

MERRICK:  Very cool!

CHUCK:  Yeah, we like Spotify.

MERRICK:  Is that the headquarters of Spotify is in Sweden?

VALERIO:  Yeah, this is the where the magic happens. They have other offices but they’re not as important as the Swedish one.

[Laughter]

VALERIO:  I’m kidding. Everybody’s important, not just the Swedish one.

CHUCK:  Very nice, very nice. Alright. So, do you guys want to just take a minute and explain what MooTools is? I think people have some idea, but just to get kind of a base line for the rest of the conversation.

VALERIO:  Yes, sure. MooTools is a JavaScript framework and this was created quite a few years ago now, like six or seven years ago, probably even more. But yeah, about seven years ago. And basically, MooTools is to enhance JavaScript rather than give you objects to work with, like wrap around stuff. It just enhances JavaScript. It’s writing the native objects prototypes. That was the main goal of MooTools, to create a JavaScript framework to enhance JavaScript. I don’t know if Arian wants to add something to it?

ARIAN:  At the moment, we are still building new stuff, that isn’t really more like the native stuff, native extending stuff and that’s super new and cool. I guess we’ll talk about it later more on this. But for the MooTools 1.X, it’s basically what Valerio said. This is super cool, stable and good to use.

CHUCK:  Now, MooTools has been around for a while, hasn’t it? Is it designed to work with Node as well or just the frontend?

VALERIO:  Well, MooTools specifically wasn’t really designed to work with Node because it came out way before Node. But it does work in Node with a few processes. But yeah, it kind of does work.

The reasons, like Arian said, the new stuff that we’re building, we’re basing everything on CommonJS and NodeJS, so that’s a different story. But yeah, the MooTools that we are now wasn’t really big for Node JS.

JAMISON:   So, I wanted to ask you about that. I have not used MooTools extensively very much at all. I’ve spent a little bit of time glancing through the docs and playing with it just to prepare for this show. And I saw that the extensions of native objects like stuff on prototypes and things. And that seems like it’s falling out of fashion a lot recently and gets a lot of flack because is it a bad idea. Why did you guys choose to do it that way instead of providing like functions that you pass and things, like some of the more util libraries like underscore or something?

VALERIO:  Well, if you think about it, JavaScript is a native API to allow you to understand. It’s made of objects like even HTML elements, and string, and array and whatnot. At that time, like seven years ago or something, it was a pretty good idea. And even today, you see a lot of developers having difficulty handling graph objects like underscore or jQuery elements. And MooTools just has the methods to real time elements like you can do equation like [inaudible] and use MooTools methods. So, it is a bit difficult to work with if you’re working with other frameworks that do the same kind of thing, like prototype, for instance. If you both modify the same object, it’s going to be a problem, of course. But it’s really much easier for developers to work with. That’s what I believe in.

JAMISON:  Yeah, it does. I mean, it looks very clean because it makes a lot of sense that objects would have all these methods for extending objects and doing set operations on objects and stuff. But it just seems like some people will yell at you for doing that. Do you do anything to prevent overriding properties if they already exist? So, do you check to see if somebody already put on like a subset method or whatever, just if something is already there before you write it on to the property?

VALERIO:  Yeah. Well, MooTools is a few — adds a few methods to the array object, for instance, or the string object as well and every native object called Implement. And that method checks if there’s a previously added method to the object’s prototype. So, yeah, it doesn’t override system methods.

JAMISON:  Sweet.

MERRICK:  That approach to the API design results in some of the cleanest APIs. Like, I did MooTools for a long period of time and I just always loved how the code came out because of that. Extending the prototype, it’s a trade-off, right? It’s just — the APIs look wonderful.

Could you guys spend a little bit of time and talk about the Class System? Because I think that’s one of the coolest systems of MooTools. You guys have the Implements. And I noticed you guys are also working on a library called Prime to bring that Class System into Node. Could you guys talk a little bit about that and the goals behind it?

VALERIO:  Yeah sure, absolutely. I can talk about the class as it is in MooTools 1.X. And basically, the idea was to have an easier system to work with prototype or an Inheritance. So, we have a lot of helper methods to extend the class, or implement new methods to a class. And maybe call the parent function of a method, the parent method of a method, for instance. And yeah, that was the main goal of the MooTools 1.X class module, basically to have a proper parent implementation to be able to call the parent’s class parent method. I don’t know if that’s clear or not, but yeah. And in Prime, I think Arian could talk a bit about the Prime implementation since he’s working on it a bit.

ARIAN:  Prime is basically the same as class, except it tries to be very lightweight and small. And you can create a new class and inherit it from another object. That’s really easy, except when you want to call a super method then, you have to do it yourself. Or you can use utilities we are writing to make that easier. We tried it to be as easy and clean as possible. It works in Node and it’s really, really cool.

VALERIO: Basically, the idea is that to have a proper parent function to work in MooTools 1.X, we had to have a lot of trade-offs. There are a bit of speed concerns, as well. It’s not that bad. It works and it’s tested and everything. But we’re exploring a much simpler solution without having to like rock methods and other methods and stuff like that in the new stuff in Prime.

[Crosstalk]

VALERIO:  Yeah, like that.

MERRICK:  Okay. I’ve been looking at Prime and I have high hopes for the project Milk. And Milk was, from my understanding, kind of taking MooTools and making it into AMD. But I haven’t seen any activity on that. Is that because you guys have decided to stop working on that and start working on the CommonJS newer stuff or…

VALERIO:  Yeah. Basically, we decided to scrap the Milk project and go to CommonJS instead. And the modules are pretty much the same ones that we had in Milk but we just put those in Prime and Elements and Agent and moo.fx. It’s still modular but we decided to go CommonJS instead of AMD.

MERRICK:  Beautiful! And are there any new design goals or are you guys still aiming to enhance the native JavaScript with these libraries? Or are you going to make that optional? I heard some talk about that letting you install the prototype methods versus having them there.

VALERIO:  Yeah, exactly. In the new stuff, it’s going to be optional. We are still writing the API as prototypes but we’re not going to expose those to the native objects by default, basically. And you’re going to have to do it yourself, if you want to.

MERRICK:  Very cool.

VALERIO:  You can still use like generic methods, for instance, if you don’t want to extend the native objects. You could use what we call a Ghost which is kind of like underscore, basically. A bit different but yeah.

MERRICK:  Is it like the wrapping approach of objects?

VALERIO:  Yeah, exactly.

MERRICK:  Okay. Is Prime kind of considered the next step for MooTools then? Is that what you guys are thinking Prime, Elements, all these kind of modular pieces, is that going to be MooTools 2, so to speak?

[Crosstalk]

VALERIO:  Yes, exactly. That’s 4, I guess.

[Crosstalk]

ARIAN:  So, it’s stuff that you can upgrade to the new stuff. It’s like you have to rewrite a lot, and design goals are quite different.

MERRICK:  Yeah. And okay. So, I’ve been looking at the Prime stuff recently a lot and I really like it. I like all the stuff you guys do. My question is, it’s very CommonJS-driven. And so, to use it in the browser, you have to build it essentially and the build — I saw you guys write your own build tool like WrapUp or something like that. It’s WrapUp, right?

ARIAN:  It’s WrapUp.

MERRICK:  And for those that don’t know, WrapUp is a CommonJS tracer. It will trace your module’s path and they’ll kind of make CommonJS build and work in the browser. That’s really simplified. But is there any hope or any plans of making these modules compatible with like RequireJS without a build?

ARIAN:  Exactly. In the last WrapUp release, we had a support for converting CommonJS to AMD. Basically, the CommonJS is really similar to AMD except that AMD wraps in a defined function. So, in WrapUp, we take the object syntax tray, we add some sugar, then we output it JavaScript and that’s AMD basically for each module. So, it’s really easy if you just output to AMD and then you can use RequireJS if you like that.

MERRICK:  Alright, cool. Thank you. I’m looking forward to that.

VALERIO:  If I can add something to this. Basically, the conclusion that we came to is that AMD is not a good source definition, module definition format. It’s not a good source format. CommonJS is the best source format that exists today and every other format has its own use and its strengths and its features. Every other format can be basically built from CommonJS. But for instance, if we add AMD as the source format, we wouldn’t be able to build CommonJS as easily or use it in Node.js. That’s why we decided to use CommonJS as a source format and WrapUp takes care of every other format that we might want to support with a build system.

MERRICK:  That’s actually a terribly good argument for using CommonJS as your source. I really like that.

CHUCK:  So, one thing that I want to ask and I’m going to drop the jQuery word.

JAMISON:  Someone already used it once. So, you’re not the first.

CHUCK:  But it looks like this is a viable alternative to jQuery. I’m wondering if MooTools gives you any capabilities that jQuery doesn’t give you and vice versa. If jQuery gives you anything that MooTools doesn’t give you?

JAMISON:  Can I answer this as like an impartial observer first and then we’ll get the real answer?

CHUCK:  Go for it.

JAMISON:  So, one thing that MooTools looks like it does a lot better job is with modularity. Everything is split up in to totally separate modules that you can decide to include or not. And jQuery, everything is just, it’s all there. It’s all on the $ sign. And so, if you decide you only want to use the function prototype stuff, or the object prototype stuff, then you can use that. Or if you want to just have a nice class syntax, you can use that. But with jQuery, you kind of get it all. And there’s not really much choice in what you build into it. I’m sure there are many more differences but that was the one that struck me.

MERRICK:  I would actually like to give an impartial answer too, if that’s cool before they’re real answer.

JAMISON:  You’re not impartial, Merrick.

[Laughter]

[Crosstalk]

MERRICK:  I view jQuery as a domain specific language for the DOM. And MooTools is, because of its modularity approach and gives you some sort of object approach, it kind of brings in some of the elements that you find in like Backbone. So, all of the structural things that you like in a framework like Backbone, MooTools kind of has it built because they’ve built things around this Class System and they have just things like that. Cookie, JSON, good animation stuff. So, it’s like — it’s hard to explain but it’s more structured than jQuery code. So, you don’t need the appendage like Backbone if you use MooTools. Now, for the real answer…

VALERIO:  Maybe you said everything. Yeah, it’s modularity and adding a system that doesn’t lock you into like DOM specific code, that’s really it.

CHUCK:  So, are there instances where you would use MooTools over jQuery, or jQuery over MooTools, and have it be a clear victory? Or is it just a matter of taste?

VALERIO:  Well, as I see it, jQuery is really, really nice for inexperienced people with JavaScript, in general. It’s a really good library. Even if you just need to work with the DOM which isn’t always easy, jQuery is a really nice option. It’s a solid DOM library and I really like it for what it is. That’s what I would…

ARIAN:  Oh, my God! You just said we should be using jQuery?

[Laughter]

VALERIO:  Yeah, I do. As a DOM library, it’s really solid.

JAMISON:  That was kind of a backhanded compliment. jQuery is good if you don’t know JavaScript. But you’re super smart and you’ll use MooTools, basically.

CHUCK:  Well, I can kind of see it both ways. Because for example in Ruby, that’s what I spend most of my time working in, you can use Rails without really understanding Ruby. But you don’t really get all the power out of it until you really understand Ruby and the underlying language. And it sounds like that’s kind of what they’re saying is, jQuery is probably more approachable for people who aren’t as familiar with the idioms and thinking around the way that JavaScript works. But once you understand what JavaScript gives you, then MooTools is a powerful tool because it actually then just amplifies your ability to work in JavaScript itself instead of obstructing all of the tricky and hard pieces away and sometimes hobbling you a little bit so that you don’t go wander off into the swamp.

JAMISON:  How do I add numbers with jQuery?

VALERIO:  Yeah. That’s a good question.

JAMISON:  That’s the classic jQuery developer question. I want to add numbers and I have jQuery, how do I do it?

[Laughter]

VALERIO:  Basically, what I meant was that jQuery is way more approachable than MooTools. And that’s not a bad thing. An experienced JavaScript developer can also use jQuery and he’s going to use jQuery much better than like a non-JavaScript developer. But yeah, a non-JavaScript developer can probably use jQuery with a certain degree of success. Well, if he uses MooTools, then he’s not going to be really happy, really.

MERRICK:  MooTools gives more than just DOM stuff, right? They differ in that sense because they give you utilities for functions like function.from and attempts, and chains and nicer things for — what do you call it?

ARIAN:  And class, of course.

MERRICK:  Yeah, and class.

ARIAN:  Because you construct your entire code that you don’t really needed anymore. You can build good structured code without Backbone.

MERRICK:  Exactly. So, I’m kind of a MooTools fan boy obviously. Actually I started with MooTools and learned jQuery. So, I kind of went the other way than, I suppose, most people. But I’m grateful for it because I feel like MooTools taught me JavaScript.

CHUCK:  So, if MooTools is more of kind of an advanced JavaScript or enhanced JavaScript, I guess you could say, and jQuery is more of a DOM library, can you use them together?

VALERIO:  Yes, you can.

JAMISON:  I was just reading a blog post…

VALERIO:  A lot of people are doing that, using jQuery for the DOM things and MooTools for the rest. And it’s working pretty good.

CHUCK:  So, there’s no tricky interplay between it, at least for most things?

VALERIO:  No, none at all. In MooTools, for instance, you can decide to create your own build without the DOM stack completely. You could leave that out completely and then just use jQuery.

MERRICK:  Which is so funny because jQuery’s actually starting to get that. Now they’ve moved to Grunt. jQuery 2, I think, is going to let you do somewhat modular builds. And MooTools has been doing that since I can remember, since I was in high school.

JAMISON:  That was like last year, Merrick. Come on!

[Laughter]

CHUCK:  Yeah, I know that jQuery UI actually has — it’s a bunch of widgets for your website that kind of add on to jQuery. And that one, you can pick which widgets you want to include and exclude the rest. It’s nice to hear that jQuery’s kind of going that way.

JAMISON:  So, I wanted to talk about — I’m going to say the J word one more time. So, jQuery, it seems like it has found a place as kind of the plumbing for some higher level MVC frameworks. I know Backbone expects something, jQuery.lite. Ember uses jQuery. Are there any frameworks that are using MooTools that kind of abstract away all their DOM stuff or does it fill a different role, do you think?

ARIAN:  There are actually some. I’ve seen frameworks for MooTools. They’re not as famous as Ember or Backbone. I know two. It’s just Epitome and Neuro, and maybe some others. There are also Backbone adaptors that basically mimic the jQuery API. So, they do exist. And you can still use class for most things.

VALERIO:  Yeah. But the thing is that if you’re building a framework and you depend on MooTools, then you’re going to have all the native extension baggage which I think is not that good for frameworks. So MooTools wasn’t really built as a base for frameworks. While the new Prime stuff, it is good for that, basically. I can understand why not many people want to depend on MooTools for building frameworks, and that’s a good point actually. And that’s also why we decided to go a slightly different way for the new stuff.

JAMISON:  So, is there anywhere to look at the new stuff because all the stuff on the website looks it’s still 1.X.

ARIAN:  Yes, it’s on Github.

JAMISON:  Oh, cool.

MERRICK:  Is it like something you want people to look at or are you still…?

VALERIO:  Yeah, absolutely. We’re not really publicizing it yet. We aren’t really writing blog posts or anything like that yet. But everything is kind of released. It’s available in MPM, you can install it, you can use it, it does have a version. So, it does have documentation and tests. And we didn’t really publicize it yet for a lot of reasons, maybe because it’s still version 0.X.

JAMISON:  That might change a lot still.

VALERIO:  Might change a little bit right now, yeah. That’s the main reason but it’s pretty stable and tested and documented. So, it’s going to come. We’re going to announce it pretty soon.

JAMISON:  Well, for not wanting to publicize it, you sure are talking about it on a podcast. You might have just done it.

[Laughter]

CHUCK:  So, I want to talk about some of the APIs that I’m seeing just playing with the demo page. One of the things that I saw that I thought was really, really cool was the Chaining. Do you want to just explain really quickly how that works, or how you’ve seen it used to great effect?

JOE:  It’s the function chain. So, it’s like, this, then this, then this.

ARIAN:  If you have an object and each method just returns itself then you can chain.

VALERIO:  Was it the animation chain maybe or the chain…?

CHUCK:  Yes, that’s what you used it for, was an animation chain.

ARIAN:  It’s the class chain.

VALERIO:  Oh, yeah, yeah, yeah. That was basically a utility for creating animation — chains of animations. It wasn’t really that big of a deal. It’s just kind of like…

ARIAN:  It’s two lines of code basically, if I remember correctly.

VALERIO:  Yeah.

CHUCK:  Yeah. The thing that I really liked about it was, for example, if you have some workflow that needs to happen or if you have a series of different things that you want to occur, rather than creating one big function that says, “Do this, and this, and this, and this, and this, and this,” or triggering a bunch of events. Effectively what you do is you just say, “Do this and then chain this next thing on to it.” And so, you can discreetly break apart the pieces of what is supposed to happen. And then, just chain them all together, at least in theory. I haven’t played with this too awful much. You could wind up with much cleaner code because all of the different effects are lined up and then just happen in the order that you chain them together.

[Crosstalk]

VALERIO:  Especially in Node, it’s useful. All you have to — with all the asynchronous channel systems and stuff.

ARIAN:  I really like this async. It’s one of the most popular packages on MPM and  it’s basically the same thing, only it provides a lot more. You can like async and then parallel and then it executes functions in parallel or series, or net, and then return stuff. It’s really nice. You should look at it

VALERIO:  You can probably see the chain is closer to this new Promises thing, maybe.

MERRICK:  That’s what I see. It’s kind of like ‘Chain’ kind of is what ‘Then’ is in a very high level approach. It’s essentially like — it takes observer and calls the next function that’s passed into it.

VALERIO:  Yeah.

CHUCK:  Yeah. I’ve just been clicking through some of these others. A lot of them look like some of the things that you get out of jQuery or jQuery UI where it’s just element manipulation. So, you can look it up, you can do drag and drop, things like that. I’m a little curious. One other thing, before I get into that, that I really like was that the Request API for doing Ajax calls and stuff, that seemed really, really clean to me. When we complained about this on the show before, the API in jQuery to do Ajax request or in XJS, which is another one that I’ve been using recently. It’s really, really ugly. And this seemed just a whole lot more — I don’t know. I just liked it a little bit better. I mean, it looks a lot the same but at the same time…I don’t know.

MERRICK:  The request? That’s what I was saying with the APIs is because of the approach of like [inaudible] enhancing it, the APIs tend to look a lot cleaner in MooTools 1.X. Like, request et cetera, they look like you would expect them to look.

JAMISON:   So, part of that seems like it’s because it’s organized a lot more around objects instead of imperative procedural stuff. And jQuery feels a little bit like you’re chaining specific operations together or just kind of telling the computer what to do in these steps. And this looks a lot more like you’re creating objects that model the behavior you want.

VALERIO:  Both of the approaches have their own strengths. Our approach is more — I think it gives you more power in the end to do whatever you want to do. But it’s also a bit more cumbersome to begin with, to start a new project or a new request. And it is a bit cumbersome to have to specify all the options. It gives you more power in the end, the approach with all the options and stuff. But it is a bit more difficult to use, I guess.

MERRICK:  To your point, Jamison, it stands for My Object Oriented Tools. So, it’s definitely based more on objects in that case.

JAMISON:  Ah, sneaky. I didn’t know that.

CHUCK:  I just thought somebody had a thing for a cow.

[Laughter]

VALERIO:  That’s probably the real reason behind it. But yeah, officially, it’s My Object Oriented.

CHUCK:  That was really, really slick. So, what’s your favorite instance that you’ve seen MooTools used in? So, it could be a website or library that builds off of MooTools?

VALERIO:  Well, I might be a bit on the side here but I really like it being used in the Spotify web player. That’s probably because I work here.

[Laughter]

ARIAN:  Actually, my favorite website using MooTools is 9GAG. I visit it everyday. So, that’s really cool.

CHUCK:  So, I’m a little curious, what part of MooTools are you most proud of?

VALERIO:  Without any doubt, the Class System. That was the main reason also why I started with MooTools in the first place, to write a better Class System for JavaScript.

CHUCK:  Okay. What about you, Arian?

ARIAN:  Well, I was going to say the same but I’m getting fond of WrapUp, which is the CommonJS build tool we recently made. I did a lot of work on that and I really like it.

JOE:  So, the Class System and WrapUp, those are really awesome things. I’m wondering with the Class System, you guys mentioned that Prime is kind of changing the approach to that. Are you going to see a similar amount of power in the Prime object system?

ARIAN:  It is a bit less powerful in some ways because you can’t use parent methods as easily as in MooTools. But it’s pretty much the same concept.

JOE:  Okay.

VALERIO:  To me, it’s a little bit of ease with speed.

ARIAN:  Well actually, for the parent method I created Prime-util and that provides a way to call parent methods more easily. It’s not as easy as in MooTools 1.X, but it’s okay.

JOE:  Cool. You actually have a pointer to the parent, right?

ARIAN:  Yes, it’s like on the pointer type of the parent object, so you can just call it.

JOE:  Cool.

JAMISON:  Can I just make a radical change of subject?

CHUCK:  Go ahead.

JAMISON:  We kind of talked about this a little bit throughout the podcast but we never really got the whole story. So, do you want to talk about kind of the history of MooTools and where it came from? Because I know it’s a lot older than some of the other frameworks around there. But I don’t know that much about it because I haven’t ever used it.

VALERIO:  Yeah, certainly. The story is more or less than in 2005, I think. I started developing this little animation framework called the moo.fx. And it was a really easy way to create animation out of anything really. It could have been an HTML element property or even a numerical value, you could animate anything. And after that, I was using prototype at that time, but it didn’t really scale too much maybe because of the lack of modularity that prototype has. So yeah, after seeing how prototype didn’t fit my needs anymore, I decided to kind of start creating a new framework. So, that’s how it started.

JAMISON:  And you said that was in 2005?

VALERIO:  Yeah, 2005 or 2006.

ARIAN:  I wasn’t doing anything related to websites back then. I was like 14 or something.

VALERIO:  Grade school?

[Laughter]

ARIAN:  Yeah, more or less. But I think it was December 2005.

VALERIO:  Yeah.

ARIAN:  That was version 0.8.7, correct?

VALERIO:  Yes.

ARIAN:  That is the version that I use for everything, that release 0.8.7.

CHUCK:  So, I remember back then, I was pretty new to web development. We were using script.aculo.us. And script.aculo.us did a lot of the effects. And then, we started looking at moo.fx, and then the project ended.

VALERIO:  Okay, was that because of moo.fx?

CHUCK:  No. The project ended because the people running the project mismanaged it and ran out of money.

JAMISON:  So, your library didn’t kill their project. Don’t worry.

MERRICK:  Yehey!

[Laughter]

CHUCK:  But yeah, there were some definite advantages to going with moo.fx that we saw. But it was mainly just the comprehensibility of the code like the script.aculo.us stuff sometimes was really hard to follow.

VALERIO:  Yeah. We had a different approach to the problem really. The moo.fx was probably more of an animation library but not DOM animation library. Script.aculo.us. tried to do a lot of things like slide-ins and expands of HTML elements while moo.fx really works with numbers mainly.

CHUCK:  Okay. Well, it seems like we’re winding down. Are there any other aspects of MooTools that we should talk about before we get into the picks?

JAMISON:  I have a vital question. Does the MooTools source code use semi-colons or not?

VALERIO:  The MooTools source code does use semi-colons but the MooTools frameworks like Prime and Elements and the new moo.fx, doesn’t. I don’t like semi-colons.

JAMISON:  Everyone hates you for some reason or another, either because you use semi-colons or because you don’t. You’re safe.

[Laughter]

VALERIO:  Well, I might have semi-colons in that case because it’s easier.

[Laughter]

JAMISON:  Yeah.

ARIAN:  And it doesn’t really matter because with WrapUp, you have the semi-colons anyway for generation. So, if it works in Node, it works anywhere. So you get the semi-colons.

[Crosstalk]

JAMISON:  I don’t think it happens but I had to say something dumb to finish off the podcast.

CHUCK:  Yeah, there we go. What are the other religious battles?

VALERIO:  I think the whole discussion is stupid.

JAMISON:  Yeah.

MERRICK:  Them or EMACS?

JAMISON:  Them!

[Laughter]

CHUCK:  Alright, let’s get to the picks. Joe, why don’t you start us off with the picks?

JOE:  Alright. I’ve got two picks this week. One is the game Wasteland 2 which has not been released. Way back in the day, long before even I became a programmer, there was this game called Wasteland and it was a bomb. Loved that game, loved that game. And so, some studios picked up the IPN as pre-release [inaudible]. There are mixed reviews even though it’s like pretty awful. I’ve been pretty positive about it, so pretty excited for that. I can’t remember exactly when it’s going to be released. So, I’m going to pick Wasteland 2.

And then, my other pick is going to be a book series, it’s The Lost Fleet Series by Jack Campbell. It’s a series of something like eight books, it’s Sci-Fi series, features lots of really, really, really cool space battles. It reminds me a lot of one of my favorite Star Wars novels, Back to War or Back to Wars, I can’t remember if it’s plural or not. But it’s a pretty nice series and it’s really cool. Awesome plot, great writing, and really cool action. So, I’m going to pick that one, as well.

CHUCK:  Alright. Merrick, what are your picks?

MERRICK:  So, I’m going to pick MooTools in this episode because MooTools kind of shaped me as a programmer. It’s kind of my first dive into object-oriented programming and it’s just been awesome.

Then I’m going to pick people who can ride an airplane for the first time. I envy those people. Yeah, that’s it.

CHUCK:  Alright. Jamison, what are your picks?

JAMISON:  I have a plethora of picks today and some good alliteration. So, my first pick is this thing that Square released this week, I think. It’s the ES6 Module Transpiler. So, there’s been a lot of discussion about the ES6 Module Syntax and lots of opinions. And this transpiler allows you to use the new ES6 Module Syntax like in your code today. And you can transpile it to CommonJS or AMD. So it will actually still work with whatever system you’re using. And I think this will be really valuable to get an opinion on how it actually feels to use it instead of just kind of yell about this back which is what a lot of people have been doing.

The next one is called Song of Github. It’s a little app somebody made to take that Github contribution visualization. You know, the grid that has little squares with for what they’ve contributed or that you’ve committed stuff. So, someone wrote an app that takes that and turns it into music. So it will play chords based on the days that you contributed stuff. It’s pretty sweet. Just type your name in and listen how you sound. Type ‘Vision Media’ to hear all the notes in the world because he has tons and tons of open source stuff.

My next pick is the voting for the Open West Conference. It’s a Technology Conference out here in Utah. And it’s going on in May, I believe. But the voting for presentations just came out today. It might still be up when this episode goes out. But you should check it out if you’re around here and interested in going to this conference. There’s some good looking presentations.

My last pick, sorry, a mouthful of stuff. My last one is this Node HTTP server framework thing from WalmartLabs called Hapi. I didn’t even know that WalmartLabs existed or that Walmart did anything with technology besides create those little scooters for morbidly obese people to ride.

[Laughter]

So, that’s kind of cool just to see they did a cool stuff with node. And it’s a good looking framework. They have some interesting ideas on built-in validations of JSON data types and stuff like that. So, you should check that out too.

Those are all of them. Most picks in the world. Sorry. I’m done.

CHUCK:  Wow! Alright, I’m going to go next. I’ve got a couple of picks. One pick that somebody put up on Twitter, they were replying to something that somebody said on the Ruby Freelancer show. And I just thought it was funny. It’s cornify.com, I think. Basically what it is, is it’s got a button on there and like every so often when you move the mouse around it, it makes rainbows that follows your mouse. And then if you click the cornify button, then it puts like unicorns and ponies and rainbows and all kinds of stuff on the screen. And so, if you keep clicking it over and over and over again, pretty soon your whole screen is full of glittering ponies, and unicorns, and stuff. I just thought it was pretty funny.

The other one that I’m going to pick is something that we’re doing this weekend. We’re going to the Parade of Homes in St. George. And St. George, Utah is one of those warmer climates where older people go to retire with all of their beaucoup bucks that they’ve saved up over their lifetime. So, the Parade of Homes down there, unlike the Parade of Homes up here, is basically, you get to go through a whole bunch of like million, two million, three million, six million dollar homes. And see all of the stuff that they put into them. Every year, we come back with a ton of ideas for things that we either want to do to the house that we’re currently living in or to put into a house that we may eventually build. Anyway, it’s a lot of fun. So, I’ll link to that as well.

The last thing that I want to pick is Dave Ramsey’s Financial Peace University. I just want to point out, because several people in the programming communities that I work through are not religious or not Christian. This is a very highly Christian-based thing. Most of the financial principles are sound, but he does talk a lot about his Christian faith and things. So, if that bothers you, this may not be the course for you. But if you’re up for just some sound financial advice, then go check it out. It’s really, really good. I think I spent like $100-something to get the At Home System. You can also go to a course. They have in-person courses all over the US and they’re well worth it. We just couldn’t find a scheduled time that would work for us, for the class.

Anyway, it’s just been stupendous. We’ve gone through the first four lessons which means that we’ve put together our list of debts and how we’re going to pay them off. And so, we’re doing a budget now and we’re working through a financial plan to get out of debt. And it’s awesome. I recommend it to anybody. But if you’re sensitive to, again, somebody talking about the Bible and Biblical principles and Christian faith, then just be aware that that is in there.

But yeah, those are my picks. Valerio, what are your picks?

VALERIO:  My first pick is actually related to my job which is node-libspotify. I’m going to give you a link and it’s a way to use Spotify with Node.js which is very cool. I’ve been using it for the last week, since we had a hack week at Spotify where we worked on fun projects. So, it’s very nice to do Spotify playback through Node.js.

The second pick is probably super agent from DJ which is a request class for Node.js and the browser. So basically, it keeps the same API in Node.js and the browser to make HTTP requests which I think is really, really, really nice.

And my last pick is one of my libraries, actually. It’s moo.fx version 3.0 which is on Github as well. I’m going to give you the link. The new stuff that moo.fx supports is CSS3 animations in compliant browsers, or normal JavaScript animations. And it even works in Node.js. And you can make animations with a common line or whatever. And that’s it.

CHUCK:  Awesome! Alright. Arian, what are your picks?

ARIAN:  I have two picks. The first one is from Brendan Eich blog and he talks Why Mozilla Matters, especially with Opera changing to WebKit and the WebKit 1.0 culture and he talkeds why it’s bad or not ideal to have one standard browser even though it’s open source. And according to the W3 specs, the W3C specifications, I think that’s an interesting discussion about Opera changing to WebKit.

My second pick is, I’m an Ubuntu user and I really like it. And this week, they released a preview of Ubuntu tablet and they also released Ubuntu phone. I guess today, they released the release the source code. And I hope that they can change the market at the moment like with Android and IOS. I hope they can do that but we will see. It looks really, really nice with the multitasking and you can have your phone apps at the sidebar. And then, do all the stuff on all the side of the screen. You will see how that will evolve.

CHUCK:  Yeah. I’ve looked at Ubuntu phone and some of the ideas they have there. I’m really excited that there’s going to be just another source of great ideas for phone OS’s out there.

Alright. Well, we’ll wrap this up. Thanks for coming, guys. It was really, really good to talk to you and hopefully we’ll get a few people to look at MooTools and kind of understand what the power is there.

ARIAN:  Thank you for having us.

VALERIO:  That was great.

CHUCK:  You’re welcome.

MERRICK:  Yeah, thank you guys. That was awesome.

0 comments

Previous post:

Next post: