Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.


I just landed in Vegas where i'll be for the next several days at Mix '08. I'm looking forward to hearing more about what the IE team has in store for IE 8. I've got a whole stack of questions and they've promised a frank discussion without any pre-conditions or NDAs. This oughtta be good. If nothing else, it will tell us how far retracted the IE Cone Of Silence (TM) is. I've got hope, but I've been teased before and despite an impending Beta, there's precious little to go on about what IE 8 really will and won't be (or even when).

I'm not a gambler, and generally don't like Vegas, which makes me all the more excited to be going to SxSW directly from MIX. I haven't been in a couple of years, but Dylan has been keeping the annual Dojo Salt Lick field trip alive, and I'm excited to be able to be able to join the rest of my (mostly Silicon Valley) compatriots in stumbling around Austin under the influence of Shiner and BBQ. If you're also going to be in Austin (at SxSW or not) and want to join us in our trip to BBQ Mecca, just RSVP and let us know how many you intend to bring and whether or not you can drive others.

Oh, and there will be an auspicious panel wherein authors of successful JavaScript libraries will all thank John for doing the work of proposing a panel and therefore ensuring that we all have an excuse to come to Austin to drink Shiner and eat BBQ. The last time I went to SxSW I hosted a panel with some of the smartest people I know and it went over like a lead brick, convincing me once and for all that SxSW is the Jerry Springer Show of technical conferences and that the point of panel discussions there is to stir shit up. It doesn't even matter what it is...everyone else there is nursing the same mild, Shiner-induced hang-over and if they really cared about technical content...well, they would have gone to ETech.

If you're going to either MIX or SxSW, let me know! Conferences are always more fun when you know the Hallway Track is going to rock.

Update: there's much to say about MIX now that it's over and IE 8 is in our hands, but apparently we've communicated about the Salt Lick thing very poorly. While we'd love it if you'd RSVP to rsvp at dojotoolkit dot org if you're joining us, what you really need to know is when and where. Namely:

8pm, Sunday March 9th
The Salt Lick
18001 FM 1826
Driftwood, Texas 78619

Remember, it's BYOB and if you RSVP we can help coordinate rides and such. Looking forward to seeing you there!

Keeping Up

The Dojo community is going at a clip that I can barely follow these days. Notably:

That and a whole lot more comes over the transom via Planet Dojo. Big props to Peter for keeping on top of things an adding new feeds to the Planet as they emerge.

Update: One more for the pile! Tony Issakov's Dojo Findings blog is worth a read/add, particularly as he's digging into Dojo+Jaxer

Clean Licensing: Why You Should Care (If You Don't Already)

I've written before about the importance of clean licensing to an Open Source project, but one of the things I didn't cleanly outline is the case for clean licensing from the point of users. Understanding why clean licensing is valuable to users helps to further cement why it's valuable to projects, and why well-run projects have such a hard job when it comes to building the inclusive, "lets try anything" spirit that it takes to succeed while watching out for the interests of their users down the road.

Put bluntly, it boils down to risk. What are the odds that someone contributing to the project I'm using will decide later that they've changed their mind about giving away their hard work for free, particularly if the project becomes super-successful? And what is the project doing to mitigate that risk?

It's worth remembering that the projects themselves don't often have much to fear when it comes to "unclean" contributions and are entirely unlikely to change their basic terms of distribution (unless all the code is copyright one person or legal entity), which leads many projects to take an approach of "looks good to me..." when it comes to accepting patches. Most OSS projects don't have any money, and suing an OSS project is a political nightmare. All of this means that the risk of choosing poorly is often externalized by projects. That is to say, they make it users' problem; you got the code for free and now you're whining? (but of course you're still "paying" for the code in other ways) Lastly, if the project us under the GPL, there isn't any real risk so long as the project has a public record of where patches came from (i.e., public source control that anyone can inspect).

So already we've got some big warning signs that we can look for to determine if a project is looking out for my best interests as a user:

At this point anyone familiar with even the basics of the licensing of OSS JavaScript toolkits will note with wry amusement that I'm describing a set of criteria that cast Dojo Foundation projects in a favorable light...and of course I am; we set up the Foundation's licensing policies to explicitly avoid the kinds of pitfalls that large users of OSS already know to avoid. This post is simply about helping everyone else understand that logic. That your tools of choice may not compare favorably isn't for a lack of effort on our part. As I've said over and over, we welcome any deserving project under the umbrella of the Dojo Foundation. Enough about that, though. Back to the nuts and bolts.

As a user of Open Source code, my biggest concern is always that the code does what I want it to. There are lots of creative ways to isolate poorly licensed projects when building an app, but I'd much rather not expend the effort if I can avoid it. Some licenses (in some situations) may even impact my business model, so very close behind "is it good?" in my mind is always "how's the license?". When given a set of roughly equivalent options, big OSS users often flip those concerns. For them (and possibly for you), the hassle, risk, and expense of funky licensing absolutely outweighs functionality. Some are so large in-fact that using or backing an OSS solution is simply a market expedient and not a necessity in any way. But you and I aren't that big (probably), and besides, we like our tools just fine.

And this really cuts to the crux of the issue: despite not having paid anything for the software, choosing a particular tool means investing in it. Learning the APIs alone is probably a significant investment, and porting to some other solution will require time and effort. OSS means you're not putting up cash at the get-go, but certainly as time goes on there is a very real investment in the Open Source infrastructure that we build products and projects with. How "solid" is that investment going to be? Obviously, we can't know what's going to happen in the future, but can certainly steer clear of potential problems once you know how to look for them.

Which leads to the last point, and one which I've heard parroted by other OSS project leads who haven't been as careful: are people seriously going to get sued? I mean, is this ever really going to matter?

Admittedly, Open Source licensing lawsuits are rare, and most small organizations never see them. Instead, what they see are opportunists and shake-down artists like SCO knocking on their door years later for "licensing fees" about some IP they may never know they've swallowed. The SCO suit was a weak case in part because SCO had itself distributed Linux and the kernel was GPL'd. Even the lamest and dumbest of trolls must surely have learned something from SCO's public humiliation, no?

My only answer for this is that many of Dojo's users get sued only because they have money and the sun is shining. That's not going to change because they chose Dojo or don't, but there is serious opportunity to for components like Dojo to put them in a bad situation were we not as careful as we have been about the licenses of all the components of the toolkit including images and CSS; not just code. I cringe every time I see an Open Source rich-text editing control which uses icons which could easily be confused with those from a certain (litigious and Open Source fearing) Washington-based software distributor. Those projects may never see so much as a C&D, but their users may be in for hurt. Now imagine if that were an entire UI theme and not just a couple of icons? Oof. If the projects which are saying they aren't hearing concerns from their users reflect on it a bit they may realize it's just as likely as not a question of timing and self-selection. The big OSS-savvy organizations have passed them over. Why deal with the headache?

The pedigree of the inputs into a project determines the legal risks associated with its use down the pike. Since we can't eliminate risk, only mitigate it, it pays for all of us to ask questions about the licenses of the projects our products and projects make use of now — while it's still cheap to do so. Hopefully by doing so, we'll not only push the good code to the top but also build a licensing foundation that we can work from without ambiguity or risk for decades to come.

Firefox 3 Arrays: No, You're Not Insane

I just spent 20 minutes in IRC with Wolfram staring down one of those situations where you keep swearing under your breath "println isn't broken....println isn't broken....println is NOT broken".

Catch this fun gem from FF3b2:

>>> typeof []
>>> var a = [];
>>> var b = new Array();
>>> a.constructor == b.constructor
>>> c = [];
>>> c.constructor == a.constructor
>>> d = new Array();
>>> b.constructor == d.constructor;
>>> b.constructor == a.constructor;


Extending dojo.query()

As you probably know, Dojo is layered, extensible, and our philosophy of "build with, not on" means that we give you all of the same tools and extension points that we use in our code for use by your app.

Dojo's got 2 "sides", namely the bits that make working with the DOM better and the bits that make writing idiomatic JavaScript faster and easier. Where the package and language utilities enable you to extend and modularize your JavaScript work, the widget, behavior, and query systems make working with the DOM similarly extensible. Writing widgets and behaviors is well-understood in the Dojo community, but extending the results of a dojo.query() call haven't seen as much attention. To rectify that, here's the two-minute version of how to write your own dojo.query() extension.

Step 1: grok dojo.NodeList

dojo.NodeList is the Array subclass which all dojo.query() calls return an instance of. Therefore, to extend the results of a dojo.query(), we really want to extend the dojo.NodeList class. Both dojo.query() and dojo.NodeList are available as soon as dojo.js is included in your page.

Step 2: extend NodeList the old-skool way

Instances of dojo.NodeList pick up properties from the prototype object of the dojo.NodeList class. Lets add an inspect() method which logs out the innerHTML of the nodes in the list to the Firebug console:

dojo.NodeList.prototype.inspect = function(){
    return this;

// now we can call it: dojo.query("#container > p").inspect();

// or via a direct instance: var nl = new dojo.NodeList(dojo.byId("container"), document.body); nl.inspect();

A couple of small things to note:

Step 3: modernize and package it up

We want to be able to use dojo.require() to manage this module, so we'll assume that our Acme module lives in the acme/ directly which is a peer of the dojo/ and dijit/ directories from the Dojo distribution.

Lets add a provide() so that we can require() our module and use a bit of Dojo's language tools to extend dojo.NodeList more tersely:

// this file located in:
//    acme/ext-dojo/NodeList.js

dojo.provide("acme.ext-dojo.NodeList"); // require() statements go here

dojo.extend(dojo.NodeList, { inspect: function(){ this.forEach("console.debug(item.innerHTML);"); return this; }, ... });

We can now include this module at runtime via dojo.require("acme.ext-dojo.NodeList") and use it as a part of a build which will significantly improve the performance of the application which needs the file. Dojo's infrastructure makes doing what's easy pay off in the long run for your application.

Note that the file name is acme/ext-dojo/NodeList.js, which might seem a bit odd at first glance, but the intermediate "ext-dojo" directory makes it blindingly obvious to anyone who sees the require() statement what's going on. You can't dot-access a variable named "ext-dojo", so we know that this isn't a "normal" module. Instead, it's an extension, which extends the dojo.NodeList class. Subclassing is often more trouble than it's worth, and discouraging people from extending the Dojo core objects seems lame. Instead, we use this convention to make it easy to understand what's happening when you look at any given Dojo project.

And that's it! Writing powerful extensions for query results is easy, and because your project is using Dojo, you can structure your extension as a module and gain the benefits of optimization for deployment via the Dojo build system and the ease of use that comes from not having to worry about what order you're including your files in. It's good to be using a tool that you can build with, not just on.

Older Posts

Newer Posts