Archive for the ‘‘Industry’ News’ Category

The MooTools dev team discussed the whole sizzle thing at great length over the past few days. I posted about it quite a bit and there was a lot of talk on the Google Group for MooTools users. I’ll admit that when I first read John Resig’s email I was very open to the idea and thought it was worth considering, though I was a bit conflicted. I posted my thoughts and talked with Valerio and Tom about it at length.

In the end, I felt that it was too early to tell if it was a good idea and thought it best if we waited to see what the Dojo team would do with it.

Then Valerio posted this well-reasoned post about it and completely convinced me that it’s not the right move for MooTools. I agree with him 100% at this point.

There are several reasons why a project like MooTools would never include a third party library like Sizzle in its codebase. First of all, we already have a very fast, very manageable and solid CSS selector engine in place. I worked on it a lot, I know how it works, and I know that if it ever needs a fix, every MooTools collaborator can just git it and fix it, right away. Every Mootools collaborator knows how MooTools works, what our code practices are, and how to submit either a patch (if they don’t have Git credentials), or patching the code themselves.

Well I’ve been rather obsessed lately with getting mootools running in a server-side environment. I’ve had some minimal experience with Helma, but I decided to try and build my own. At this point its rather simple, but I have managed to initiate the jetty webserver with mootools and to write java handlers in javascript (again with mootools) to handle my requests. I looked at a few internet posts about doing your own javascript web frameworks, but most I had a hard time getting to work on my local environment as well as my server environment. So after about a month of diving into Rhino documentation and Jetty documentation I’ve got something fairly predictable working.

Dylan Schiemann sent me a nice email response to this post that clears up some details:

Hey Aaron,

We’re actually voting on something different, which is whether or not
the Dojo Foundation will accept Sizzle as a project (Dojo Toolkit,
cometD, DWR, Persevere, Lucid Desktop, and OpenRecord are the other Dojo
Foundation projects).

So why does this matter? Well, it means that Sizzle will have all of
its code contributed under CLA, so it can actually be used in Dojo. It
also means the process for becoming a contributor, and making it into
what you need it to become is much easier than if it was just Sizzle
Copyright John Resig.

We literally went from discussion to vote in a total of about 3 hours
yesterday, so this all happened rather quickly.

On the toolkit level, we will start with a branch and evaluate the
results. Assuming things work great, we’ll switch over asap. If not,
then we wouldn’t make an immediate switch, but we’d work with the people
contributing to Sizzle to get us to the point of sharing code on this.
Certainly getting more of the Ajax community working together on things
we’re all duplicating across the board anyways isn’t a bad thing (it’s
really why Dojo was started).

If you have any questions or comments, don’t hesitate to ask…

Regards,
– -Dylan

This is what Dojo is doing, but I’ll also note that John (Resig), who has some comments below which I’ve responded to, sent us an email before I made my post asking if we, the MooTools team, would be interested in adopting Sizzle. So while the Dojo news on Ajaxian is about them adopting the project the question still remains regarding MooTools potential use of Sizzle.

To be clear, in my earlier post I am not advocating one way or the other. I think there are benefits and drawbacks and I’m curious as to what others think about it. Garrick Cheung weighed in with his own blog post, saying:

Aaron brings up very good pros and cons. I think we should not follow the trend and switch to Sizzle but instead take in what we can and be inspired to improve upon it. We should already be doing that. This would require our awesome MooTools dev team to be up-to-date, but aren’t they continuously learning?

I should also note that both John in his comments below and Tommocchino have pointed out that Sizzle is very extensible. The mechanism – the interface – for extending Sizzle with custom selectors is different from the current MooTools methods, but the capability is the same. Here’s what Tom wrote in the MooTools user’s group, which has had a lively discussion:

…you should note that it is extremely extensible, and things like custom pseudo
selectors are no problem at all.

CSS selectors are, by and large, all about as fast as the next now. There’s not much benefit to be had as far as speed is concerned.

While I may agree that selectors aren’t going to get much faster – the thing that is changing is the standardization of those selectors. This comes in two forms:

From standards bodies, like the W3C, with new methods (for example, querySelectorAll). If the libraries collaborate on a single engine it becomes fundamentally much easier for these new methods to come into being and propagate. It’s taking far too long for querySelectorAll to reach all of the current libraries – it should be happening much faster.

In custom selectors. There is no standardization on custom CSS selectors that libraries have. For example – there is the common custom selector [attr!=value]. What does this mean? Is it equivalent to :not([attr=value])? If that’s the case then it’ll match elements that don’t even have the attribute to begin with. Maybe it should be equivalent to [attr]:not([attr=value]). But, again, that’s not standardized anywhere. Having a unified engine allows us to standardize this in one place with a de facto implementation.

I agree with John on these points, I think. Consolidating our behavior would send a nice message to the browser vendors and the standards groups. As for some of the more complex selectors, on a personal level I don’t find myself using them that often. I think this is a product of some of the differences in MooTools and jQuery or maybe it’s my development style. I tend to prepare my DOM for easy selection without a lot of attribute selecotrs and then manage state in my classes. I’m not saying this is better than using them – just that I don’t tend to use them often. Consequently, on a personal level, my interested is just less engaged on the topics of exotic selectors and so I’m content to let others weigh in on their merits and how they should be structured. I guess what I’m saying here is that I agree with John’s first point and don’t have an opinion on the second.

Frankly, not using Sizzle will mean that MooTools will always be playing a game of catch-up. Right now jQuery, Prototype, Dojo, and YUI are all looking at using the library – that only leaves one odd library out. I’m not attempting to put undue pressure on your team – it’s absolutely your decision – but you’ll definitely be in a position, if all the libraries use Sizzle, of constantly trying to catch-up to what is implemented in the de facto implementation.

Now here I disagree. As I’ve stated previously, I think the speed that most selection engines now have are only marginally different. Sizzle is faster (esp when it caches), but I’m quite happy with the selection engine that’s present in MooTools now and don’t feel that we need to do any catching up. Yes, we could add more selector options, but if users need that they can extend our engine if they like. And yes, it would be nice to add a caching option, but I think most users wouldn’t notice it in most cases. Besides, if you’re writing your code in a MooTools style, you shouldn’t really be selecting the same thing twice unless you’ve loaded new content into the DOM, in which case the caching wouldn’t help you.

So I don’t feel like there’s a huge difference between the options that Sizzle has and the query engine in MooTools has. I also think that, by and large, these things work well enough and until browsers address these needs it’s unlikely that we’ll see any big leaps in performance, as I’ve stated elsewhere.

Sizzle caches selector results, which we could add to MooTools if we liked and we might, but perhaps this isn’t something everyone wants.

That’s something that we’ve been discussing amongst the different implementers. I see no problem with this piece of code being made optional.

Cool. I don’t think the caching thing in Sizzle is a bad idea. As I state above, I don’t ever run the same selector twice in my code unless the DOM has changed. Having this as an option would basically accommodate code styles that encourage re-selecting on the DOM. That’s cool.

The MooTools coding philosophy is definitely set on having extensible code. Anyone can author custom selectors for the MooTools selector engine and the code in the engine is very clean and understandable to any MooTools user. We’d loose some of this if we moved to Sizzle.

This is the point that I’m most confused about. I will put money down, right now, that Sizzle is more extensible than any other CSS selector engine in any of the major libraries – MooTools included. jQuery selectors have been, traditionally, very extensible but I went far beyond that with Sizzle’s implementation and you can extend any selector in virtually any direction. If there are any specific extension concerns I’d love to address them but as far as I know there really aren’t any.

I stand corrected. I’ve since spent a little more time on the topic and John is totally correct that Sizzle is very extensible. My bad there.

I don’t know about “more extensible than any other CSS selector engine” – seems to me that either the engine is extensible or it isn’t. I haven’t seen any complaints about MooTools extensibility in this regard, so we haven’t encountered a use case that our engine doesn’t handle. But regardless, I was incorrect in that statement in my previous post. My bad.

There’s something to be said about autonomy. By having its own selector engine, MooTools can add functionality and manage its own needs.

You can absolutely add your own functionality to Sizzle – in fact a number of libraries are already doing it. For example jQuery has :hidden and :visible – but keeps them within its engine – they are not a part of Sizzle. Both Prototype and MochiKit are looking to do this, as well. That’s the beauty of the extensibility here. Such an extensible architecture means that you’ll be able to add your snap-in your own functionality.

There’s a difference between being able to extend a technology and writing it yourself. There are reasons that there are so many JavaScript frameworks. There are a lot of ways to do this stuff and none of them are wrong or right. It’s a matter of personal taste. My point above is just to say that autonomy has some benefits. Again, I want to reiterate that I’m not advocating publicly whether I think MooTools should or should not adopt Sizzle. Just trying to kick off the discussion in our community.

While adding Sizzle might be a nice gesture to the community, illustrating that we can all get along together, it may not offer any other big benefits (if you don’t consider any of the Pros above big benefits).

I’m not sure what is being referred to here. It’s important to note that it’s not just illustrating that we can get along together – it’s actually getting along together. A lot can be said for standardization. If there wasn’t some form of standardization between browser vendords, for example, we’d be in a much rougher place right now.

My point here is that coming together has some nice benefits, but from a use case perspective, it’s not that big of a deal. If $$(‘div.foo’) works, our developers aren’t going to really care one way or the other. Personally, I see the benefits of using Sizzle as the selector engine for MooTools as being a net zero – it’s got benefits and negatives. In my mind, they kind of cancel each other out. That’s why I’m so keen to see what our users think of it. I could go either way.

One could argue that healthy competition is the reason we have fast CSS engines like Sizzle in the first place. If we all consolidate then maybe that innovation slacks off. One could counter that by saying that selector engines are so fast now that it’s really quite negligible and that any likely speed increase won’t come through further iteration on the JavaScript.

Two points:

You’re assuming that the only driving force of performance improvements is a specific outside force (such as another implementation). But you’re forgetting the biggest outside force of all: The users.

I’m not assuming anything nor am I forgetting anyone, thank you. But I think that competition is healthy and all of the frameworks have benefited from seeing how we all solve the same problems. MooTools has certainly benefited from Dean Edward’s work, Prototype’s work, and jQuery’s work. As Stravinsky said, ‘good composers borrow; great composers steal.’

Continuing with John’s point:

In the jQuery project we’ve been making constant performance improvements to a variety of methods and components – because it’ll make the code faster for the users – NOT because there’s some 3rd party test suite that demands we have faster numbers. With so many minds at the table (all the major libraries) it’ll mean that this library will be in front of the majority of JavaScript users, in one way or another. It will be compelled to become faster.

Again, speed, at this point, I think is moot. At least for MooTools developers. jQuery has a pattern that uses selectors a lot, which is totally cool and accessible to a lot of people writing and learning JavaScript. MooTools encourages developers to select once and manage state. I’m not arguing that one way is better or worse, but as far as I’m concerned, I’m quite satisfied with the efficiency in the MooTools selector engine.

We released SlickSpeed to be able to learn from other frameworks. If we could see that someone else was able to perform a selector much faster than we could, then we knew we had work to do. At this point the numbers are so low for most selectors and real world use cases that speed isn’t the concern anymore. Any gains we hope to make at this point are going to come from the browsers.

While the competition has been good, it also has its ugly side. For example, not a single major JavaScript library implements document-order multiple selectors (e.g. returning “h1, h2, h3? in the order in which they’re in the document – not all h1s followed by all h2s, etc.). No library does this because they would get instantly decimated on SlickSpeed. It’s going to be really important, going forward, that we start to match the published specifications (Selectors API) more closely, otherwise we are going to confuse users and break sites. Competition certainly hasn’t helped libraries to progress in this nature.

I’ll still take that healthy competition any day, and I don’t know that there has really been an ugly side. Returning results in the manner that John describes is, to me, a need the browsers need to support as doing it in JavaScript just isn’t practical. Further, I’ve written a LOT of JavaScript (though I’m not claiming that it’s more than others for sure) and only rarely – if ever – do I find myself wishing I had this kind of selector capability.

My final thoughts are that MooTools could benefit from Sizzle and being a consumer of and contributor to this common layer for all the frameworks. But there aren’t that many compelling reasons to do this right now. If it were my choice (and it most certainly isn’t) I’d be inclined to take a wait-and-see approach. If Dojo adopts the project (did that vote already pass? I’m assuming it will) then I’d want to see what Sizzle looks like on the next release. I know John will continue to be a big contributor but by handing it over to Dojo – an awesome move I think – he’s basically saying that everyone should own it. I want to see what it looks like when everyone does. Maybe then the benefits will be much more clear to me.

There’s a lovely post on Ajaxian today that the Dojo community is now voting on whether or not to swap out their own selector engine for Sizzle, Jon Resig’s CSS selector engine. Several other frameworks are considering doing the same thing. jQuery is using it already of course, but Prototype, MochiKit and others are all looking into it.

One the one hand, it kind of makes sense for frameworks to work together for these types of things. Why invent the same wheel over and over again? What about event management? Garbage collection? Why not consolidate a lot of this stuff?

As I’ve written previously, I think that frameworks are really only different from each other at the core and at the edges. That is, the way they do things at their most fundamental and abstract levels (like inheritance management and whether or not the extend JavaScript’s native objects – that sort of thing) and also the interface – the actual syntax they provide. But CSS selectors? Who cares about that? So long as the selectors use the CSS3 standards (perhaps with a few extra ones thrown in for good measure) the interface is the same, right? I mean, jQuery(‘div.foo’) vs $$(‘div.foo’) – the interface – what those methods ($$ and jQuery) return is what matters – who cares what the engine is that finds all the divs, right?

This is middle-ware. Sure, a year or two ago, the selector engines in frameworks were very different and some where far faster than their counterparts. But the MooTools team released Slickspeed and set off an arms race for selector engines. This competition was really good for everyone and is the reason that almost all the frameworks are so fast now. Why keep hacking at this problem if it’s basically solved. The only way that selectors are going to get fasters is if the browser developers continue to optimize the JavaScript engines.

So, as I see it, here are the pros and cons of swapping out the MooTools’ selector engine for Sizzle.

Pros

MooTools benefits from development contributed by all the other framework authors. Someone on the Dojo team figures out how to do something faster, and whammo, MooTools gets it, too. The obverse is true as well – MooTools can contribute to the speed and stability of other frameworks in the same way.

It means fewer bugs that the MooTools developers have to squash. When new browsers show up that introduce new capabilities, core the developers don’t have to drop everything to rework things.

It sets a precedent for the notion that the framework teams out there (including the MooTools team) don’t have to write everything themselves. Let’s focus on what makes our frameworks different and delegate the things that make them similar.

It makes it easier to move from one framework to another. Custom selectors and the like are available to all frameworks.

More clout can be had with the browser vendors if all the frameworks are using the same standard.

It would show that the frameworks can actually agree on something for a change and that this isn’t a competition.

Cons

CSS selectors are, by and large, all about as fast as the next now. There’s not much benefit to be had as far as speed is concerned.

Sizzle caches selector results, which we could add to MooTools if we liked and we might, but perhaps this isn’t something everyone wants.

The MooTools coding philosophy is definitely set on having extensible code. Anyone can author custom selectors for the MooTools selector engine and the code in the engine is very clean and understandable to any MooTools user. We’d loose some of this if we moved to Sizzle. I have since been corrected here: Sizzle is very extensible.

There’s something to be said about autonomy. By having its own selector engine, MooTools can add functionality and manage its own needs.

While adding Sizzle might be a nice gesture to the community, illustrating that we can all get along together, it may not offer any other big benefits (if you don’t consider any of the Pros above big benefits).

One could argue that healthy competition is the reason we have fast CSS engines like Sizzle in the first place. If we all consolidate then maybe that innovation slacks off. One could counter that by saying that selector engines are so fast now that it’s really quite negligible and that any likely speed increase won’t come through further iteration on the JavaScript.

Are there other pros and cons I haven’t thought of? I feel like I’m missing something, I dunno.

What are your thoughts as a MooTools user (if you are one)? Does this even matter to you? Do you have a preference? Would it make you happy to see MooTools adopt this standard bit of code or would you rather see MooTools maintain its own query engine?

For those of you who are GreaseMonkey hackers I’ve created a fork of MooTools Core on GitHub that can be loaded into a GreaseMonkey script via @require. We’ve been using this fork for our open source meta/hack/web project ShiftSpace. You’ll need need to have ruby and the json ruby gem installed on your machine in order to build the mootools-core.js file.

Debunking Dojo Toolkit Myths
The Dojo Toolkit has been around for over four years, and has undergone significant changes, both big and small, in becoming a great JavaScript toolkit. This article debunks myth and outdated assumptions (both fair and false) applied to Dojo over its four plus years of development.

And this, finally, led me to the third big thing. The thing that reaffirms my choice of MooTools. All the frameworks out there are increasingly becoming very similar to each other at the edges. I.E. they all eventually look something like this:

The only real difference is terminology. One framework might use $, another might do something like, oh, Y.get, or jQuery(id), followed by different verbs that are synonymous with the next framework. At the edges, they all do the same thing. This is because we all see good patterns in each others’ work and incorporate it – again, we’re all working against the same thing – the browsers – for the same purpose.

But where they are different is deep down in the core.

Dylan’s post does a great job debunking a bunch of myths about Dojo. Again I find myself thinking that the framework teams are indeed on the same side and which framework is right for you is determined more by your own sense of style than anything else. That style is increasingly less evident at the edges, as I put it above. It’s the core of these frameworks that have the interesting bits.

A few months ago I put it on my list to learn more about jQuery. I feel that I can notch that off my to-do list (though I’m no expert certainly). Now I think I need to go spend more time with Dojo. I’m not looking for a replacement for MooTools or anything, just some new ideas.

As many of you know, I left CNET back in November of 2007 to pursue my own startup (www.iminta.com). While getting that off the ground CNET continued to contract me to maintain the Clientside public libraries and to continue blogging here. I also worked on a few internal projects as I was needed. This was a tremendous help as it afforded me the time to do things like launch Iminta.com and finish the MooTools book. Considering that CNET was the principal investor in my first startup (way back in 1999), in one way or another, CNET employed me for nearly a decade, and I can’t thank them enough.

But all good things must come to an end, and my contracting work for them is now officially over. Consequently, Clientside.CNET.com is no more. I started thinking about domain names a week or three ago and eventually settled on Clientcide – as in death to the browsers! This was really a reflection of what I and other developers of JavaScript frameworks have been saying for a while: the frameworks aren’t competing with each other – it’s the browsers we’re at war with.

Now that I’m not speaking for a large public company here, I felt free to play around with the look-and-feel and my early designs were all things like browser icons with blood splattered across them, Kill Bill style. But these ultimately felt too derivative and then I stumbled upon the idea of just making the header stupid fun. I must say, I’m enamoured with the new look. We’ll see if I feel that way after a few months of it. What do you think?

It’s taken far longer than I originally had hoped, but we’ve finally managed to tackle a few big changes here at clientside.

Redesign

First, there’s a new design. It’s not really much different than the old one, but it’s a bit cleaner and crisper. You should really notice the change in the wikitorials.

Mootorial.com; Updated Wikitorials

Speaking of the wikitorials, we’ve relaunched those, too. You’ll find that all our code for MooTools 1.2, which we relaunched in June, now has tutorials and demos. We released the code when it was ready, but only just now managed to re-author all the tutorials, which were sadly out of date.

Then there’s the MooTorial – the MooTools tutorial that has drawn so many of you here. It’s now moved, officially, to www.mootorial.com. It’s still a part of Clientside and brought to you by CNET, but now it’s seperate from our code and much better organized (and updated for MooTools 1.2, of course).

The MooTools Book!

Well, it took waayyy longer than I would have suspected, but the MooTools book is finally here! You can purchase and download the PDF of the book immediately, or order the paper version, which comes out in the next day or so. You can get the PDF from Apress (the publisher) or order the paperback from Amazon.

The book is over 250 pages of step-by-step instructions on how to use MooTools. It’s similar to the Mootorial in that it covers every class and method in the library, but it’s far more detailed and designed for both advanced programmers and beginners. Hopefully you’ll find it a useful reference and an easy read.

Michael Mace, a former Palm VP, says the business of native mobile apps is dying. He includes a quote from Palm veteran Elia Freedman summarizing why some of us have found mobile application development to be a deeply frustrating experience.

From the technical perspective, there are a couple of big issues. One is the proliferation of operating systems. Back in the late 1990s there were two platforms we had to worry about, Pocket PC and Palm OS. Symbian was there too, but it was in Europe and few people here were paying attention. Now there are at least ten platforms. Microsoft alone has several â€” two versions of Windows Mobile, Tablet PC, and so on. [Elia didnâ€™t mention it, but the fragmentation of Java makes this situation even worse.]

This isn’t strictly clientside material, but it may be of interest to those of you reading here. The nutshell is that CNET operates an affiliate program. If your blog or site or newsletter or whatever sends traffic to us that then clicks through to one of our merchants, you get 30Â¢.

We also have a rich API that lets you pull data into your environment. Sign up for a developer key and integrate us into your site a little and now you can provide a lot of interesting meta data about whatever it is you’re talking about. Cars, ipods, cellphones, TVs, etc.