February » 2009 » Clientcide (Formerly CNET’s Clientside)

Archive for February, 2009

No, I’m Not On Vacation

February 28th, 2009 by Aaron N.

I’ve been rather quiet here for the last few weeks. Aside from the fact that I started a new job as I mentioned previously, I’ve been working probably 2/3s of my evenings for the last few weeks on MooTools More, which at this point is essentially code complete. I feel bad about not posting here – there certainly have been plenty of things I wanted to write about, but all I can manage to do is tweet them on @mootools.

So since I haven’t been here posting like I usually do, I thought I’d give you a glimpse into my MooTools to-do list which doesn’t include my day job (where I’ve been writing gobs of cool JavaScript, some of which I’ll release, I promise). This list is feeling quite oppressive right now – I feel very behind – so hopefully sharing it will be both cathartic for me and also will explain my lack of posting to those of you who have missed my super awesome posts lately.

MooTools More: Download Page

The new MooTools More has a lot of functionality. I want a download builder similar to the one here on Clientcide. This will become especially important as the official plugins are broken up into separate libraries. For instance, all the language translations are in their own repository. So I have to rewrite the More Builder for mootools.net, which isn’t a small task.

MooTools More: Review Lighthouse Bugs

Before we release the new MooTools More I want to review the 60+ bugs in Lighthouse thoroughly and identify any that are especially ugly, any that are invalid or duplicates, and then the others that are perhaps just annoying. My objective is once the new -more is out there to have a weekly or bi-weekly release with a bug fix or two and a new feature or two. Constant, iterative development.

MooTools More: Hand Off MooTools Lang

I launched the MooTools Lang Google Group where people who want to help translate things in -more can contribute and discuss that aspect of the work in detail. I don’t want to manage this stuff. I split all the language files off into mootools-lang on github and now I just need to find a ~~poor sucker~~ enterprising soul to own it.

MooTools More: Testing!

We now have tests for every plugin in the library (over 40 now and that will grow quickly). Now we just have to churn through them all in every browser we want to support and fix any issues that crop up. I can see IE6 out of the corner of my eye like it’s stalking me.

MooTools More: RC1

Actually pushing out a release candidate is a big milestone and we’re basically ready for it. This just means things like the docs pages, download page, and a nice long blog post are prerequisites.

MooTools More: Wikitorials

After RC1 is out, I need to go through all the wikitorials here on Clientcide and move the pages for the plugins that are moving to -more over to the MooTorial.

MooTools More: Compatibility

There are only one or two changes to existing MooTools More plugins that will require compatibility files, but there are numerous changes to the scripts coming from Clientcide (one or two are minor breaking changes that can be fixed with a simple search and replace). I need to author all these and then test them so that people using the versions here on Clientcide can migrate easily.

MooTools More: Demos

We’ll need to author demos for MooTools.net that show off all this great new stuff.

MooTools Book

Did I mention I’m working on the second edition of the MooTools book? This version will cover MooTools 1.3 as well as a lot more detail of how to use MooTools. All the inner workings of the library and how you can use them most effectively – a best practices for MooTools kind of thing. This is all the stuff I didn’t have time for in the first book (the last three chapters were all I could get in there before the deadline). It’s shaping up to be about twice the size of the original (you’ll be relieved to know that the font size will not be ginormous like the first book – I still don’t know why Apress did that). Given that the book has been out since August and I still have no clue how it sold and have not received any payment for it, it seems like thankless work. Not to mention the fact that I’m trying to rewrite the book to be about MooTools 1.3 which is still very much in development. Every day I turn around and Valerio has something completely different checked in. Every time he makes a change I think to myself, well, I’m gonna have to rewrite the mootorial pages about that, these two chapters of the book, these plugins in MooTools More, and these plugins on Clientcide. Yay!

As it is I’m on the hook to deliver a chapter every four days (!!!) in order to stay on schedule, and that’s assuming 1.3 doesn’t change much as I go and that it’s on schedule, which I have no control over. In case I’ve never given you this advice, I’ll give it to you now, for free: never write a technical book. If only I had taken my own advice and left it at the first edition, but alas, I was never satisfied with the first edition which I felt was left unfinished.

Clientcide Bugs

Previously I tried to stay on top of bugs that crop up in the Clientcide code. A few bugs were either too esoteric for me to fix (I’m sorry, but I simply refuse to support Chrome or Safari 4 beta yet), but for the most part, if someone filed a bug because something wrong in my work was blocking them, I’d stop what I was doing and try and fix it. Because of my focus on MooTools More lately, I haven’t been able to do this. I’ve fixed a few bugs – the easy ones and the bad ones – but still, I have eighteen bugs open, some of which I can tell are going to be painful to fix. Every time a new one comes in I cringe because I simply cannot focus on this stuff yet. For those of you out there who are stuck because of these bugs, I am truly sorry.

As you can see, my cup runeth over. I know what you’re thinking. You’re thinking I am insane.

Increasingly, I think you may have a point there.

Posted in 'Industry' News | 8 Comments »

More Friday Fun: Devthought Makes It Rain

February 20th, 2009 by Aaron N.

MooTools -more developer Guillermo Rauch launched a new version of his excellent blog Devthought and brings some fun with him.

Posted in Examples | Comments Off

Friday Fun – mParallax: MooTools Parallax

February 20th, 2009 by Aaron N.

I’m not really sure what the use case for this script is other than “make something awesome”, but it’s very cool. mParallax “turns a selected element into a ‘window’, or viewport, and all its children into absolutely positioned layers that can be seen through the viewport. These layers move in response to the mouse, and, depending on their dimensions (and options for layer initialisation), they move by different amounts, in a parallaxy kind of way.”

For all you people using MooTools to make your own 8-bit side-scrolling NES clones, this is your library.

Posted in 3rd Party Libraries | Comments Off

MooTools Powered CSS Sprites

February 19th, 2009 by Aaron N.

A few months back David Shea wrote an article on A List Apart about CSS sprites that inspired Uruguayan MooTools developer Gonzalo Rubio (aka gonchuki) to take the practice and apply using MooTools:

While the original version used jQuery (1.2.6 at that time) and lots of people like it, we (mootoolers) have a different approach to code specially emphasizing on OOP techniques and readability. Part of the issue might not be jQuery per-se and be Dave’s code that was a little obfuscated, but it anyways has a lot of room for improvement.

This article will just describe differences between the MooTools implementation and the Dave’s jQuery one, so unless stated otherwise, everything from the ALA article applies here.
new Sprites2({mode: 'fade', item_selector: 'ul.nav a', duration: 250});
(this is just a screenshot from the post)

Check out the full post for details and to download the code.

Posted in Best Practices, MooTools | Comments Off

Comparing Frameworks with Inheritance Benchmarking

February 19th, 2009 by Aaron N.

Over on Ajaxian yesterday was a post about benchmarking inheritance methods that was pretty interesting (here’s the post that Ajaxian was covering). In it, various methods for extending objects in JavaScript are compared:

Ad hoc inheritance – This is a common(?) homebrew technique for allowing prototypes to leverage the code in objects further up the prototype-food chain. Methods are overridden by keeping a reference to the parent method in a separate property , which can then be invoked as needed. It’s fast but not very pretty, and it’s arguable whether or not this qualifies as real “OO” inheritance.

Prototype-style inheritance – Prototype uses a strategy inspired by Alex Arenell’s Inheritance library. Subclass methods declare a “$super” argument that is set up by Prototype to reference the superclass’ method.

Base2-style inheritance – Dean Edwards’ library. Subclass methods invoke “this.base()” to call their superclass’ implementation.

John Resig inheritance – JR, of jquery fame, experimented with a Base2 variant which he published on his blog. It’s a bit simpler than Base2, but seemed worth testing.

Read the rest of this entry »

Posted in MooTools, Optimization | 5 Comments »

Sizzle and MooTools by the Numbers

February 12th, 2009 by Aaron N.

There’s been a bit of hullabaloo this morning around a comment John Resig made on David Walsh’s blog where he asserts that Sizzle is 2x faster than MooTools. I posted this morning about how this is somewhat of an unfair comparison – that Sizzle is a selector engine and MooTools is a framework (that has its own selector engine).

The real question here is not which selector engine is faster (though that’s pertinent) but which framework is faster, by how much, and if it’s enough to matter. Valerio’s thoughtful post about why MooTools wouldn’t use Sizzle outlined several reasons why it doesn’t make sense, but the biggest reason is that the MooTools selector engine is actually faster than Sizzle when used as the MooTools selector engine. In other words, if MooTools dropped in Sizzle (which is larger in file size) for its current selector engine, our users would not see a benefit. This is really the main issue – he wasn’t arguing that MooTools is faster or as fast as jQuery – only that including Sizzle didn’t make sense.

So David posts instructions on how to use Sizzle, if you really want to, in MooTools. He asserts that doing so would provide no performance benefits and no functional benefits, which is really just an echo of Valerio’s argument. Again, he’s not comparing MooTools to jQuery – just that Sizzle + MooTools doesn’t really get you anything, and I agree.

So in an effort to understand that question, just that question – is MooTools w/ Sizzle faster or slower than MooTools without it, I put together a new SlickSpeed test. This test is the default SlickSpeed (Valerio made a version originally to test Sizzle that only ran the selector once because Sizzle used to cache but it doesn’t any more – this version of SlickSpeed runs each test numerous times).

In an effort to answer the main question, I’ve included in this test Sizzle, the MooTools selector engine on its own, and MooTools, and MooTools using Sizzle (as David outlined in his post). For good measure, I also include jQuery, though as it doesn’t post-process elements, you’ll see that it’s basically on par with Sizzle, as it should be.

I’ve made a google spreadsheet that others can add their results to. I’ll update this graphic below as more data comes in. I don’t have FF2 or IE8 handy, so if someone would be so kind as to fill that in…

As you can see, MooTools + Sizzle isn’t faster than MooTools on its own. This is the main question I wanted to answer.

This means that the selector engine in MooTools is the right choice for MooTools. If you look at the graphs though, you’ll see that in IE, MooTools really suffers. This is because IE doesn’t allow you to alter Element.prototype. As a result every time MooTools uses its selector engine in IE there is an overhead as each returned element must be extended with the new methods at that time. This is a design decision and it’s something we’re working on. Expect to see this aspect of performance improve in MooTools 1.3.

But as far as selector engines are concerned, Sizzle isn’t appreciably faster than the MooTools engine, especially when it’s used as the engine in MooTools.

I’ll finish with a portion of one of the comments I made this morning:

Our frameworks actually don’t have any other benchmarking method that I know of – selectors are the only thing. There’s no benchmark for CPU usage during animation or whatever.

But now the improvements are small. The initial speed-ups were orders of magnitude. We’re now squabbling over milliseconds. In a real world app, we’re talking about something like, maybe 50ms or so difference in performance for all the selectors running on a page. That’s what I mean by it not being a priority. Yes, maybe we could make MooTools perform 50ms faster, or a 100ms, but at this point, it’s not where we feel the biggest return on our investment lies.

After looking at the results of this test I think it’s reasonable to focus on speeding up how MooTools extends Elements, but not the selector engine. Expect to see improvements on that front in MooTools 1.3.

Some Input From The jQuery Team

Before I posted the above info I sent it off to Rey Bango. Aside from wanting to get advice from someone with a mustache, I thought it would be good to speak to someone on the jQuery team, and he fit both bills. Rey’s input to this post (which I haven’t altered other than to add this footnote) was the following:

“Our frameworks actually don’t have any other benchmarking method that I know of – selectors are the only thing. There’s no benchmark for CPU usage during animation or whatever.”

We have tests for DOM manipulation and event delgation which [are included in this set of tests as documented here].

I played with these tests which John has said “Sizzle is optimized to work best on the selectors that developers actually use – and the test represents that.” My issue with the test is that it is very repetitive – it tests against the same type of selectors repeatedly (#page, #masthead, #mastheadhd – essentially all just $ calls in MooTools – you wouldn’t use $$ for them – and .mastheadbd, .first, and .on which are all basically the same kind of selector – on a single css class name). John has created a version of SlickSpeed that repeats the types of selectors his framework is optimized for. Of course it performs faster. His argument that “MooTools optimizes for the wrong selectors” is, I think, presumptive. It would instead be accurate to say that it is not optimized for jQuery development.

The other point Rey made to me was he agrees with me that “we’re reaching the threshold of what can be achieved”. There are other things that need to be optimized, but at this point we’re trying to squeeze blood from a stone in many respects. In MooTools, we need to work on our post-processing to speed that up in IE. There are other things like DOM creation and manipulation that we need to optimize.

Included in the tests that Rey sent over were tests for DOM injection and event delegation, but I’m not convinced that the suite is real apples to apples. For instance, MooTools delegation doesn’t exist in the framework (I have a beta version in my own scripts, but that’s not official). The tests compare delegation in jQuery to MooTools standard event management which isn’t optimized for that sort of thing.

I’m sure that as such a test suite matures and is contributed to by other frameworks such as ours that we’ll see optimization race forward as we have with selectors. As it is, I’m still pretty convinced that Sizzle isn’t any faster than MooTools’ selector engine.

Posted in 3rd Party Libraries | 9 Comments »

Sizzle is 2x Faster than MooTools Selector Engine? Say Wha?

February 12th, 2009 by Aaron N.

David Walsh posted yesterday a bit of code that will let you use Sizzle in MooTools if you want to. This brought a comment from John Resig (author of jQuery and Sizzle):

John Resig:

Umm… your performance numbers are horribly out of date (over 2 months, at this point). In fact, Sizzle is now over two times faster than MooTools (as of jQuery 1.3). In fact, it looks like Sizzle is going to become another 15-25% faster in the release corresponding with jQuery 1.3.2.

There’s a full thread discussing this over on Hacker News, where I address this point and more (concerning the integration).

David Walsh:

Thank you for bringing the speed improvements to my attention. As I’m sure you noted, I’m simply linking to the MooTools blog’s Slickspeed. Do you have an alternate Slickspeed link available?

I mean no offense with this post — in fact, I showed users how to make the choice themselves.

John Resig:

@david: No harm felt! Just wanted to clear up any misconceptions. A full breakdown of the methodology, the tests used, and the resulting data can be found in the jQuery 1.3 Performance notes.

Now, anyone who read Valerio’s in-depth and thoughtful post on why MooTools doesn’t use Sizzle will recall this bit:

Third, as some of you might already know, MooTools post-processes every node resulting from any query. This tends to make things slower. Sizzle however is a pure engine, therefore makes no post-processing at all. This results in a very unfair comparison.

In an effort to test the true efficiency of our CSS selectors engines, I have made a modification to SlickSpeed, so that it runs every test only once, and a couple of modifications to the MooTools code. This special testing version of MooTools no longer “extends” the resulting nodes (I did that by simply adding a method that passes an optional parameter to the default function getElements, as I cannot pass parameters using SlickSpeed), and it uses querySelectorAll where available, just like Sizzle does. This way we can have a true comparison between engines, instead of frameworks and engines.

So John says David’s performance numbers are “horribly out of date” – but are they? Well, see for yourself:

MooTools vs Sizzle 0.9.3

This is the same test Valerio put together 2 months ago except with the latest version of Sizzle (last modified 3 days ago). As you can see, it’s not faster than MooTools by any significant margin. Some selectors are faster in Sizzle than in MooTools and vice versa. When I run the tests, they repeatedly come out very close to each other. 2x faster? Indeed.

Update

I’ve posted an update: Sizzle and MooTools by the Numbers.

Posted in MooTools | 29 Comments »

What’s Up With Clientcide?

February 10th, 2009 by Aaron N.

It’s been a slow two week or so and I thought I’d post a quick note to let everyone who might be interested know what I’ve been up to, since I obviously haven’t been spending my time posting here.

As I mentioned last week, I started a new job (at Cloudera) and obviously that’s taken up a lot of my time. But as I mentioned last week, part of my job here is to continue doing what I’ve been doing here on Clientcide and with MooTools.

The other thing that’s been taking a lot of my time – my MooTools time – is the work that continues on developing the new MooTools -more library, which will start off as being the plugins currently there (Drag, Accordion, etc) plus a collection of scripts available here on Clientcide (about 20 of them). Moving them into MooTools has proven to be a rewarding but time consuming process that is still in process.

So I’ve been hard at work for you fine folks, but just haven’t had time to post much. I’ll try and get back to my usual two or three posts a week as soon as I can. Otherwise our satisfaction guarantee entitles you to a full refund.

Posted in 'Industry' News | 5 Comments »

Designing Web Interfaces

February 10th, 2009 by Aaron N.

I haven’t had a chance to read this yet, but I’m going to go ahead and suggest you go get a copy of Bill Scott’s book, Designing Web Interfaces.

You should also watch this presentation, on which the book is likely based. I saw him give this talk at Google and then brought him in to CNET to give it again to our crowd.

Bill Scott was the lead user experience evangelist at Yahoo and is now at Netflix. He’s an interesting mix of good engineer and good experience designer and I’ve spoken with him on numerous occasions about various challenges and he always gives great insight.

Posted in Best Practices | 2 Comments »

Advanced Debugging w/ JavaScript

February 4th, 2009 by Aaron N.

I have in my drafts lists in wordpress here an article called “Debugging JavaScript” that I started in April of 2007. I got about half way through the article and realized it was a daunting subject and I didn’t have time to do it justice that day. Thereafter, whenever I logged into worpress to write something, that draft would be staring me in the face. Taunting me. I’ve always wanted to go finish it, but just could never bring myself to really write it the way it needed to be written.

Well, thank god for A List Apart, who published an awesome article today on Advanced Debugging w/ JavaScript. Whew. It’s like a weight has been lifted from my shoulders.

When used effectively, JavaScript debuggers help find and squash errors in your JavaScript code. To become an advanced JavaScript debugger, you’ll need to know about the debuggers available to you, the typical JavaScript debugging workflow, and code requirements for effective debugging. In this article, we’ll discuss advanced debugging techniques for diagnosing and treating bugs using a sample web application.

Posted in Reference | 2 Comments »