I had a chance last week to share some of my thinking here to an unlikely audience at EclipseCon, a wonderful experience for which my thanks go to Mike Milinkovich and Ian Skerrett for being crazy enough to invite a “web guy” to give a talk.

One of the points I tried (and perhaps failed) to make in the talk was that in every platform that’s truly a platform it’s important to have a stable conceptual model of what’s “down there”. For Java that’s not the language, it’s the JVM. For the web…well…um. Yes, it bottoms out at C/C++, but that’s mostly observable through spooky action at a distance. The expressive capacity of C/C++ show up as limitations and mismatches in web specs all the time, but the essential semantics — C/C++ is just words in memory that you can do whatever you please with — are safely hidden away behind APIs and declarative forms that are unfailingly high-level. Until they aren’t. And you can forget about composition most of the time.

For a flavor of this, I always turn back to Joel Webber’s question to me several years ago: why can’t I over-ride the rendering of a border around an HTML element?

It’s a fair question and one I wrote off too quickly the first time he posed it. We have <canvas> which lets us draw lines however we like, so why can’t we override the path painting for borders? Why isn’t it just a method you implement like in Flex or Silverlight?

Put another way: there are some low level APIs in the web that suggest that such power should be in the hands of us mortals. When using a low-level thing, you pay-as-you-go since lower-level things need more code (latency and complexity)…but that’s a choice. Today’s web is often mysteriously devoid of the sort of sane layering, forcing you to re-build parallel systems to what’s already in the browser to get a job done. You can’t just subclass the right thing or plug into the right lifecycle method most of the time. Want a <canvas>? Fine. There you go. Want a <span>? Hot <span>s coming up! But don’t go getting any big ideas about using the drawing APIs from <canvas> to render your <span>. Both are magic in their own right and for no reason other than that’s the way it has always been.

The craziest part in all of this is that JavaScript does exist in the web so you can strictly speaking do whatever you want. Goodness knows that when the platform fails us today, we’re all-too-willing to just throw JS at it. It’s crazy, in this context then, that spec authors seem to be trying to uphold a golden principle: JavaScript doesn’t exist. Writing it out of the story allows you to just claim that your bit of the system is magic and that it doesn’t need an exposed lifecycle and plug-in architecture. New things can just be bolted onto the magic, no layering required. It’s magical turtles all the way down.

You can see why people who think in terms of VM’s and machine words might find this a bit ahem limiting.

But how much should we “web people” care about what they think? After all, “real programmers” have been predicting the imminent death of this toy browser thing for so long that I’m forgetting exactly when the hate took its various turns through the 7 stages; “Applets will save us from this insanity!”…”Ajax is a hack”…”just put a compiler in front of it and treat it as the dumbest assembler ever” (which is at least acceptance, of a sort). The web continues to succeed in spite of all of of this. So why bother with the gnashing of teeth?

Thanks to Steve Souders, I have an answer: every year we’re throwing more and more JS on top of the web, dooming our best intended semantic thoughts to suffocation in the Turing tar pit. Inexorably, and until we find a way to send less code down the wire, us is them, and more so every day.

Let that picture sink in: at 180KB of JS on average, script isn’t some helper that gives meaning to pages in the breech, it is the meaning of the page. Dress it up all you like, but that’s where this is going.

Don’t think 180KB of JS is a lot? Remember, that’s transfer size which accounts for gzipping, not total JS size. Oy. And in most cases that’s more than 3x the size of the HTML being served (both for the page and for whatever iframes it embeds). And that’s not all; it’s worse for many sites which should know better. Check out those loading “filmstrip” views for gawker, techcrunch, and the NYT. You might be scrolling down, looking at the graphs, and thinking to yourself “looks like Flash is the big ticket item…”, and while that’s true in absolute terms, Flash isn’t what’s blocking page loads. JS is.

And what for? What’s all that code doing, anyway?

It’s there for three reasons: first, to clean up the messes that browser vendors aren’t willing or able to clean up for themselves; second, to provide an API that becomes the new platform, and lastly to provide the app-specific stuff you are trying to get across. Only the last one is strictly valuable. You’re not including JQuery, Backbone, Prototype or Dojo into your pages just because you like the API (if you are, stop it). You’re doing it because the combination of API and even behavior across browsers makes them the bedrock. They are the new lisp of application construction; the common language upon which you and your small team can agree; just don’t expect anyone else to be able to pick up your variant without squinting hard.

This is as untenable as it is dangerous. It was this realization that set me and Dimitri Glazkov off to build a team to do something about it more than a year and a half ago. The results are showing up now in the form of Web Components and Shadow DOM, Mutation Observers as plumbing for Model Driven View, and a host of new CSS capabilities and JavaScript language expressiveness wins. If that sounds like a huge pile of seemingly un-related work, let me walk back to one of the motivating questions and then I’ll fast forward to the approach:

What would it mean to be able to subclass an HTML Element?

We observed that most of what the current libraries and frameworks are doing is just trying to create their own “widgets” and that most of these new UI controls had a semantic they’d like to describe in a pretty high-level way, an implementation for drawing the current state, and the need to parent other widgets or live in a hierarchy of widgets.

Heeeeeyyyyyy….wait a minute…that sounds a lot like what HTML does! And you even have HTML controls which generate extra elements for visual styling but which you can’t access from script. This, BTW, is what you want when building your own controls. Think the bullets of list items or the sliders generated by <input type="range">. There are even these handy (non-constructable!?!) constructors for the superclasses in JS already.

So what would you need access to in order to plug into that existing system? And how should it be described? This, by the way, is the danger zone. Right about this point in the logical chain most folks tend to fall back to what they know best: C++ hacker? Give ‘em a crappy C++-inspired high-level-ish JS API that will make the people yelling loudest stop beating you up. Declarative guy? Force everyone to describe their components as separate documents and…yeah. XUL. You get the idea. JavaScript person? Demand the lowest level API and as much unwarranted power as possible and pretend you don’t need the browser. JS libraries are the “fuck it, we’ll do it live!” of the web.

None of these are satisfying. Certainly not if what we want is a platform of the sort you might consider using “naked”. And if your “platform” always needs the same shims here and polyfills there, let me be candid: it ain’t no platform. It’s some timber and bolts out of which you can make a nice weekend DIY project of building a real platform.

So we need to do better.

What does better look like?

Better is layered. Better is being able to just replace what you need, to plug in your own bits to a whole that supports that instead of making you re-create everything above any layer you want to shim something into. This is why mutable root prototypes in JS and object mutability in general are such cherished and loathed properties of the web. It is great power. It’s just a pity we need it so often. Any plan for making things better that’s predicated on telling people “oh, just go pile more of your own parallel systems on top of a platform that already does 90% of what you need but which won’t open up the API for it” is DOOMED.

Thus began a archaeology project, one which has differed in scope and approach from most of the recently added web capabilities I can think of, not because it’s high-level or low-level, but because it is layered. New high-level capabilities are added, but instead of then poking a hole nearly all the way down to C++ when we want a low-level thing, the approach is to look at the high-level thing and say:

How would we describe what it’s doing at the next level down in an API that we could expose?

This is the reason low-level-only API proposals drive me nuts. New stuff in the platform tends to be driven by scenarios. You want to do a thing, that thing probably has some UI (probably browser provided), and might invoke something security sensitive. If you start designing at the lowest level, throwing a C++ API over the wall, you’ve turned off any opportunity or incentive to layer well. Just tell everyone to use the very fine JS API, after all. Why should anyone want more? (hint: graph above). Instead of opening doors, though, it’s mostly burden. Everything you have to do from script is expensive and slow and prone to all sorts of visual and accessibility problems by default. If the browser can provide common UI and interaction for the scenario, isn’t that better most of the time? Just imagine how much easier it would be to build an app if the initial cut at location information had been <input type="location"> instead of the Geolocation API we have now. True, that input element would need lots of configuration flags and, eventually, a fine-grained API…if only there were a way to put an API onto an HTML element type…hrm…

In contrast, if we go declarative-only we get a lot of the web platform today. Fine at first but horrible to work with over time, prone to attracting API barnacles to fill perceived gaps, and never quite enough. The need for that API keeps coming back to haunt us. We’re gonna need both sides, markup and imperative, sooner or later. A framework for thinking about what that might look like seems in order. Our adventure in excavation with Web Components has largely been a success, not because we’re looking to “kernalize the browser” in JS — good or bad, that’s an idea with serious reality-hostile properties as soon as you add a network — but because when you force yourself to think about what’s already down there as an API designer, you start making connections, finding the bits that are latent in the platform and should be used to explain more of the high level things in terms of fewer, more powerful primitives at the next layer down. This isn’t a manifesto for writing the whole world in JS; it’s a reasonable and practical approach for how to succeed by starting high and working backwards from the 80% use-case to something that eventually has most of the flexibility and power that high-end users crave.

The concrete steps are:

1. Introduce new platform capabilities with high-level, declarative forms. I.e., invent new tags and attributes. DOM gives you an API for free when you do it that way. Everyone’s a winner.
2. When the thing you want feels like something that’s already “down there” somewhere, try to explain the bits that already exist in markup in terms of a lower-level JS or markup primitive. If you can’t do that or you think your new API has no connection to markup, go back to step 1 and start again.
3. When it feels like you’re inventing new language primitives in DOM just to get around JS language limitations, extend the language, not the API

On the web, JavaScript is what’s down there. When it’s not, we’re doing it wrong. It has taken me a very long time to understand why the Java community puts such a high premium on the “pure java” label, and fundamentally what it says to others in the community is “I appealed to no gods and no magic in the construction of this, merely physics”. That’s a Good Thing (TM), and the sort of property that proper platforms should embody to the greatest extent possible.

And this brings me to my final point. C/C++ might be what’s “down there” for web browsers, but that’s also been true of Java. What separates the web and Java, however, is that the Java community sees their imperative abstraction that keeps them from having to think about memory correctness (the JVM) as an asset and many “web people” think of JS as pure liability. I argue that because of the “you’re gonna need both sides” dynamic, trying to write JS out of the picture is a dumb as it is doomed to fail. JavaScript is what’s “down there” for the web. The web has an imperative backbone and we’re never going to expose C/C++ ABI for it, which means JS is our imperative successor. The archaeological dig which is adding features like Web Components is providing more power to JS by the day and if we do this right and describe each bit as a layer with an API that the one above builds on, we can see pretty clearly how the logical regress of the “you must use JS to implement the whole browser” isn’t insane. JS itself is implemented as C/C++, so there’s always room for the mother tongue and of course many of the APIs that we interact with from JS must be C/C++; you can’t write it out of the story — but that doesn’t mean we need to design our APIs there or throw bad design decisions over the wall for someone else to clean up. It is high time we started designing low-level stuff for the web in idiomatic JS (not IDL), start describing the various plug-in points for what they are. We can provide power from our imperative abstraction to and through our declarative layer in ways that make both high and low-level users of the web platform more able to interoperate, build on each other’s work, and deliver better experiences at reasonable cost. That’s the difference between a minefield and a platform. Only one of them is reasonable to build on.

The trash truck just came by which means it’s 6AM here in almost-sunny London. WordPress is likewise telling me that I’m dangerously out of column-inches, so I guess I’ll see if I can’t get a last hour or two of sleep before the weekend is truly over. The arguments here may not be well presented, and they are subtle, but layering matters. We don’t have enough of it and when done well, it can be a powerful tool in ending the battle between imperative and declarative. I’ll make the case some other time for why custom element names are a good idea, but consider it in the layered context: if I could subclass HTMLElement from JavaScript in the natural way, why can’t I just put a new tag name in the map the parser is using to create instances of all the other element types? Aside from the agreement about the names, what makes the built-in elements so special, anyway?

Cognitive dissonance, ahoy! You’re welcome

Note: this post has evolved in the several days since its initial posting, thanks largely to feedback from Annie Sullivan and Steve Souders. But it’s not their fault. I promise.

If you’re already using Dojo, this should be a no-brainer upgrade. It’s out-and-out better. As a quick example, dojo.create("tagname", { /*properties*/ }) is now the preferred way to build DOM nodes quickly. Its simple API will be natural to anyone who has used dojo.attr(). Even better, Pete’s exciting PlugD version of dojo.js has been updated to 1.3 as well.

1.3′s Core features the new “Acme” CSS selector engine which provides a big boost in speed for many operations in the fast-path. I blogged before about the work we did to make Acme fast, and rest assured it is (in aggregate, across all use cases) quicker than any other selector system you can get your hands on today. But selector performance isn’t where it’s really at, and I’ve been saying that for a long time.

Luckily, Pete Higgins decided to prove it and has been working on a new set of benchmarks with the help of other toolkit vendors (to ensure fairness) called “TaskSpeed“. Dojo 1.3 wins by a wide margin. Across all the reported browsers so far, Dojo is at least 2 times faster than other toolkits on common DOM operations. We’ve worked very hard over the years to make sure that Dojo’s APIs don’t encourage you to do things that will hurt you later, and TaskSpeed finally shows how much this philosophy pays off:

Given that DOM is the primary bottleneck in most apps DOM is a big bottleneck in today’s apps, usually just behind network I/O and these tests demonstrate how Dojo’s approach to keeping things fast pays off not just on micro benchmarks like CSS selector speed, performance improvements to single toolkit functions, or even file size – but on aggregate performance where it really matters. Dojo’s modern, compact syntax for these common operations doesn’t slow it down, either. For instance, if you go check out the TaskSpeed reporting page, you’ll see that where browsers are slowest (IE6/7/8, etc.), Dojo’s focus on performance pays off most. Why use a toolkit that’s going to hurt you when it really counts, particularly when Dojo so easy to get started with? Dojo’s Core has been designed from the ground up with APIs that encourage you to do things that are fast and keep you from doing things that are slow unless you really know what you’re doing. In some cases, we’ve made hard size-on-the-wire tradeoffs in order to keep actual app performance speedy. That hard engineering doesn’t show up in micro-benchmarks or single test release-over-release improvements or the “my toolkit is smaller” comparisons that some would prefer that web developers focus on. It’s easy to win rigged games, after all. It’s only when you see APIs composed together in real-world ways, across browsers, that you can start to see the real impact of a toolkit’s design philosophy. Dojo is designed to help you make things that are awesome for users, and that means they need to be FAST.

Other toolkits have released performance numbers of late, and most of them have been either reported badly or run without much rigor, so it’s exciting to see everyone finally pitching in to build end-to-end tests that show how library design decisions interact with real-world realities of browsers. The TaskSpeed tests have been designed to be both even-handed and reliable (no times below timer resolution, etc.). The reporting page is also designed to make the results understandable and put them in context. A lot of care has been taken to keep this benchmark honest. JavaScript developers have suffered at the hand of chart junk for far too long.

I can’t do 1.3 justice in a single blog post, so I recommend that you check out these resources and then just dive in:

• Pete’s release announcement
• The Official 1.3 Release Notes
• The new Documentation (at Dojo Campus)
• The new 1.3 Core Cheat Sheet
• PlugD: An even easier way to get going with Dojo
• Run the TaskSpeed tests for yourself then see how the toolkits stack up (hint: everything you thought you knew about JS library performance was probably wrong.)
• Check out integrations for Dojo that you can probably drop right in to your workflow, no matter what stack you’re using: , Spring Web Flow (Java), Dojango (Django/Python), DRails (Ruby/RoR), Tatami (Java/GWT), Zend (PHP), or Dojomino (Domino Server).

Big thanks to the folks who tried out the betas and RC’s and helped make 1.3 solid.

As far as I know, it was a total surprise to the Dojo community (myself included). I can’t wait to get started writing apps for this thing and see what device APIs Palm has surfaced.

Maybe.

These things matter only in regards to how well they represent end-user workloads and how trustworthy their findings are. The first is much harder than the second, and end-to-end benchmarking is pretty much the only way to get there. As a result, sites like Tom’s Hardware focus on application-level benchmarks while still publishing “low level” numbers. Venerable test suites like SPECint have even moved toward running “full stack” style benchmarks which may emphasize a particular workload but are broad enough to capture the wider system effects which matter in the real world.

Marketing departments also like small, easily digestible, whole numbers. Saying something like “200% Faster!” sure sounds a lot better than “on a particular test which is part of a larger suite of tests, our system ran in X time vs. Y time for the competitor”. Both may be true, but the second statement gives you some context. Preferably even that statement would occur above an actual table of numbers or graphs. Numbers without context are lies waiting to be repeated.

With all of this said, James Ward’s Census benchmark makes a valiant stab at a full-stack test of data loading and rendering performance for RIA technologies. Last month Jared dug further into the numbers and found the methodology wanting, but given some IP issues couldn’t patch the sources himself. Since I wasn’t encumbered in the same way I thought I might as well try my hand at it, but after hours of attempting to get the sources to build, I finally gave up and decided to re-write the tests. The result is Census 2.

There are several goals of this re-write:

• Fairness. Tests need to be run multiple times for them to be representative in any way. Likewise, systems not being directly tested need to be factored out as much as possible. C2 does this by reducing the number of dependencies and running tests (at least) 5 times and discarding outliers before reporting an average. I’ve also worked to make sure that the tests put the best foot forward for all of the tested technologies.
• Hackability. Benchmarks like Census serve first as a way for decision makers to understand options but second as a way for developers to know how they’re doing. Making it trivial to add tests helps both audiences.
• Portability. The test suite should run nearly everywhere with a minimum of setup and fuss. This ensures that the largest numbers of people can benefit from the fairness and hackability of the tests.

The results so far have been instructive. On smaller data sets HTML wins hands-down for time-to-render, even despite its disadvantage in over-the-wire size. For massive data sets, pagination saves even the most feature-packed of RIA Grids, allowing the Dojo Grid to best even XSLT and a more compact JSON syntax. Of similar interest is the delta between page cycle times on modern browsers vs their predecessors. Flex can have a relatively even performance curve over host browsers, but the difference between browsers today is simply stunning.

Given the lack of an out-of-the-box paginating data store for Flex, RIAs built on that stack seem beholden to either Adobe’s LCDS licensing or are left to build ad-hoc pagination into apps by hand to get reasonable performance for data-rich business applications. James Ward has already exchanged some mail with me on this topic and it’s my hope that we can show how to do pagination in Flex without needing LCDS in the near future.

The tests aren’t complete. There’s still work to do to get some of the SOAP and AMF tests working again. If you have ideas about how to get this done w/o introducing a gigantic harball of a Java toolchain, I’m all ears. Also on the TODO list is an AppEngine app for recording and analyzing test runs so that we can say something interesting about performance on various browsers.

Census 2 is very much an open source project and so if you’d like to get your library or technology tested, please don’t hesitate to send me mail or, better yet, attach patches to the Bug Tracker.

Update: I failed to mention earlier that one of the largest changes in C2 vs. Census is that we report full page cycle times. Instead of reporting just the “internal” timings of an RIA which has been fully boostrapped, the full page times report the full time from page loading to when the output is responsive to user action. This keeps JavaScript frameworks (or even Flex) from omitting from the reports the price that users pay to download their (often sizable) infrastructure. There’s more work to do in reporting overall sizes and times (“bandwidth” numbers don’t report gzipped sizes, e.g.), but if you want the skinny on real performance, scroll down to the red bars. That’s where the action is.

To my great surprise, I’ve been at SitePen two and a half years. It has been nothing short of wonderful which may explain why it doesn’t feel like it has been that long. When I look back at what we’ve accomplished it’s also surprising that we’ve been able to do all if it in such a short timeframe. Between the huge client projects and re-building Dojo from the ground up, it has been busy bordering on nutty.

It already makes me sad to leave behind working with the SitePen crew, many of whom I helped to hire in and who I count among my closest friends. But I won’t be entirely gone. I’ll still be contributing to Dojo in my new role, if less frequently. Not that it’ll slow the project down any. Pete, Bill, Adam, and Tom have Dojo well in hand and have been driving things forward at a furious rate. Dojo has always been a team effort, and I’m excited about the improvements coming in 1.3. I’ve gotten a dis-proportionate amount of the credit over the years (and not enough of the blame), and as Dojo evolves from here it will continue to be because companies like SitePen, Uxebu, AOL, and IBM have all been able to contribute to make it happen and that leaders like Pete Higgins have stepped up to lead and teach and learn with the community. My deepest thanks go to Dylan and SitePen for having let me be a part of that process on a daily basis for the last couple of years.

So what could possibly pry me away from such a sweet, sweet gig at SitePen?

In a word, Chrome.

Three years after many of my friends joined Google, the appeal of getting to fix the “web as platform” problem from the inside has finally proven irresistible. There’s much to do, and the WebKit platform seems like the best shot that we have (collectively) at forging a future that’s not just open, but also markedly better. At SitePen I’ve had the chance to make the web a better place through Dojo. At Google I’ll have a chance to do it from the browser itself.

To the friends I’m leaving, it was a privilege to work with you. To the friends I’m joining, thanks for your trust and faith.

Today, Dojo’s delegate() function is a straightforward implementation of the Boodman/Crockford delegation pattern which Doug calls “beget” and which ES 3.1 will refer to as Object.create:

1
2
3
4
5
6
7
8
9
10
11
12

dojo.delegate = (function(){
    // boodman/crockford delegation w/ cornford optimization
    function TMP(){};
    return function(obj, props){
        TMP.prototype = obj;
        var tmp = new TMP();
        if(props){
            dojo._mixin(tmp, props);
        }
        return tmp; // Object
    }
})();

This function returns a new object which looks to the old object for things it does not itself have. Imagine an object foo which contains pithy truisms:

var foo = {
  science: "rocks!",
  learning: "is how you know you're alive"
};

We now want to promigulate our opinions, so we can delegate the responsibility of forming them:

var bar = dojo.delegate(foo, {
  testify: function(){
    console.debug("science ", this.science, "and learning", this.learning);
  }
);

Now, our bar object can change its mind independently of foo, but until it does, it’ll behave as though foo‘s views are its own:

bar.testify(); // outputs: "science rocks and learning is how you know you're alive"
 
// bar refines its opinion
bar.science = "is a process"; 
bar.learning = "requires humility";
foo.science == "rocks!"; // still true
 
bar.testify(); // outputs: "science is a process and learning requires humility"

But what about when the chain gets deeper? The fact that bar can’t “see” foo‘s values via this isn’t much of a problem when the hierarchy isn’t very long, but if you’re specializing a behavior or complex interaction, making it possible to get at the parent’s values for properties and methods becomes more pressing.

Neil has previously written about lightweight subclassing, but for as good as it its, it doesn’t get us all the way there either. In regular OO-style languages, the inheritance system gives you an out via a “super” keyword or convention. This type of property shadowing-with-exceptions is a huge boon to composition in class-based languages, but it’s not the whole story. Indeed, the Traits paper was all about the shortcomings of this special-purpose mechanism. What we want for both long delegation chains and long inheritance hierarchies is a more general system; in essence a way to say “I want to control how things are shadowed and which ones an item points at in each level of the hierarchy”.

What if we could make delegate() savvy of this type of indirection? Here’s my quick prototype:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

delegate = (function(){
    var tobj = {};
    var TMP = function(){};
    return function(obj, props){
        TMP.prototype = obj;
        var tmp = new TMP();
        if(props){
            var remaps = props["->"];
            if(remaps){
                delete props["->"];
                for(var x in remaps){
                    if(tobj[x] === undefined || tobj[x] != remaps[x]){
                        if(remaps[x] == null){
                            // support hiding via null assignment
                            tmp[x] = null;
                        }else{
                            // alias the local version away
                            tmp[remaps[x]] = obj[x];
                        }
                    }
                }
            }
            dojo.mixin(tmp, props);
        }
        return tmp; // Object
    }
})();

This new version of delegate() accepts a specially named “->” property in the list of items to add to the destination object. Items in this list can either “shadow null” (hide entirely) the parent’s property or can provide a new name for it, assuming of course that the new object will also have a property of that name. Here’s a quick example of “->” at work with our previous example. This time, foo also has a “testify” method that we’d like bar to be able to control without having to copy the implementation:

var foo = {
    science: "rocks!",
    learning: "is how you know you're alive",
    testify: function(){
        console.debug("science ", this.science, "and learning", this.learning);
    }
};
 
var bar = delegate(foo, {
    "->": {
        "testify": "grampsSays" // maps foo's "testify" to bar's "grampsSays"
    },
    testify: function(){
        if(this.science && this.learning){
            this.grampsSays(); // call the re-named "testify"
        }else{
            console.debug("this object is strikingly ignorant");
        }
    },
});
 
bar.testify(); // outputs: "science rocks and learning is how you know you're alive"
bar.science = false;
bar.testify(); // outputs: "this object is strikingly ignorant"

That New Object Smell

The last missing piece of the hierarchy pie here is that there’s no initializer for the objects which come from a delegation. A simple addition of some property detection code to look for an initializer can easily handle that:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

delegate = (function(){
    var tobj = {};
    var TMP = function(){};
    return function(obj, props){
        // boodman/crockford delegation w/ cornford optimization. 
 
        TMP.prototype = obj;
        var tmp = new TMP();
        if(props){
            var remaps = props["->"];
            if(remaps){
                delete props["->"];
                // like dojo.mixin(), except w/o key/key mapping
                for(var x in remaps){
                    // "safe" copy properties
                    if(tobj[x] === undefined || tobj[x] != remaps[x]){
                        if(remaps[x] == null){
                            // support hiding via null assignment
                            tmp[x] = null;
                        }else{
                            // alias the local version away
                            tmp[remaps[x]] = obj[x];
                        }
                    }
                }
            }
            dojo.mixin(tmp, props);
        }
 
        // support for "constructor" functions. The name "init" is arbitrary.
        if(typeof tmp["init"] == "function"){
            tmp.init.call(tmp);
        }
 
        return tmp; // Object
    }
})();

And there we have it. A style of delegation that easily supports both Trait-like name aliasing (and null shadowing) as well as internal initializers. Since our upgraded delegate can handle nulling out a parent’s value for a property, we also have a straightforward way to prevent parent initializers from being called (or being called/chained – at our discretion – by a new name):

var foo = {
    science: "rocks!",
    learning: "is how you know you're alive",
    testify: function(){
        console.debug("science ", this.science, "and learning", this.learning);
    }
};
 
var bar = delegate(foo, {
    init: function(){ this.testify(); }
});
// outputs: "science rocks and learning is how you know you're alive"
 
var baz = delegate(bar, {
    // map away the parent's constructor
    "->": {
        "init": "superInit"
    },
    // provide our own constructor
    init: function(){
        console.debug("howdy!");
        this.superInit(); // call the super-object ctor
    }
});
// outputs: "howdy", "science rocks and learning is how you know you're alive"
 
var thud = delegate(baz, {
    "->": { "init": null } // hide the parent ctor
});
// outputs: nothing

This form of delegate is likely to appear in Dojo 1.3 along with similar improvements to dojo.declare() to help alleviate the composition problems associated with using complex sets of mixins.

Update: corrected the null-out branch and updated the text with Doug’s note that beget/delegate will be called Object.create() in 3.1.

As of Zend Framework 1.6, you can include some trivial code inside your ZF views to pull in Dojo:

1
2
3
4
5
6
7

< ? 
	// setup required dojo elements:
	$this->dojo()
		->enable();
 
	echo $this->dojo();
?>

Once enabled on your page, ZF 1.6 also includes a full set of helpers to let you set up Dijit components from PHP. The excellent ZF docs has the full story. Perhaps most exciting from my perspective, though, is how simple ZF makes getting up-and-running with Dojo and how nicely it ties in with custom builds and CDN-hosted versions of Dojo as well. Matthew Weier O’Phinney and Will Sinclair recently did a screencast that walks through a lot of these options. If you’re considering ZF+Dojo, I strongly recommend you check it out.

The talk I gave on Wed was mostly focused on Dojo and the reasons we built it in the layered way that we have and how you can choose to use Dojo at whatever level of abstraction feels right for your app. Slides are here (5.1MB, PDF):

So what does Chrome mean for those of us who aren’t breaking out the champagne? Well, first, it’s the second sign (after Gears and YBP (har!)) that the content authors are taking back the web from the “browser guys”. I’ve been fascinated for the last 6 months or so by the strategic mis-alignment which results when both the browsing and authoring experience in the hands of organizations only care about one but not the other. Mozilla gets paid by search-box revenue and users download it because it’s better for browsing, therefore Mozilla is incented to build new ways to browse, but their investments in content are somewhat mis-aligned (and, frankly, it shows). Google and Yahoo, on the other hand, are critically dependent on the content getting better, so they produce plugins to augment HTML in un-intrusive ways. Chrome crosses over into the browser business from the perspective of content, and it also shows, albeit in a good-ish way. I guess we’ll need to wait and see how browsing-oriented Chrome gets (e.g., will it sprout an extensions platform – ala Firefox – or will the propsect of an ad-blocking plugin for the Google browser make that proposal D.O.A.?).

Regardless of how Chrome evolves as a product, the important question now is: how will it be distributed? The obviously non-evil thing to do is to say “look, it’s great, it’s free” and hope that the world discovers it on its own thanks to word-of-mouth and/or leverage of the Google brand. Given that Chrome delivers new awesome things which are end-user-visible (some “end-user-awesome”, if you will), there’s some real chance that Chrome can get to roughly Firefox level market-share without breaking too much of a sweat. Not that Firefox’s market share is anything to really covet, given that MoFo/MoCo have been toiling at it for a decade now. To get real, honest-to-god leverage out of this process, Chrome is going to need something like 60+% market share, and that means changing ingrained user habits. I put the probability of that happening without distribution channel love at roughly bupkis.

Microsoft killed Netscape by bundling the browser with the OS. Apple is making inroads by bundling. Firefox is even getting aggressive. So where does this leave “don’t be evil”? Given the toolbar promotional deals which Google has cut in the past, I think there’s some organizational capacity inside the Goog to use the distribution channels they’ve already created as a way of getting to critical mass. What I don’t see, though, is a view of how to bring the mission of Gears into alignment with Chrome (or vice versa). They’re both important, but Chrome is a long-term bet while Gears is the near-future solution. They are not in opposition, but their strategies for gaining leverage over the problems facing content authors are very different.

We need what Gears can offer to every browser right now while Chrome dukes it out for market share on the browsing experience merits. Hopefully, if nothing else, the Chrome installer will add Gears to other browsers on the system that users install Chrome to. Even if they don’t pick the googly experience for browsing day-to-day, perhaps Chrome can still serve to give new tools to the content-author side of the house. Other browser vendors won’t do such a thing since they win or loose on an exclusive “I must replace the other guy” basis. Here, Google (and by “Google”, I mean “the open web”) wins either way. Hopefully Google’s interest in making the content experience better trumps the “we’re all browser guys now” instinct in this case.

We’ll find out tomorrow, I guess. Here’s to hoping.

Regardless of how good it feels to see our numbers recognized for all the hard work that has gone into the Dojo design, I think it’s also good to keep them in perspective. Most of the available query engines are “fast enough” – although there’s really no reason why your query engine of choice should be twice as slow as Dojo’s, given that ours is 100-point Open Source. Having a native implementation is nice, but the primary benefit now is in reducing the number of bytes we need to send on the wire, not in actual query speed advantages. Making queries faster isn’t in the critical path for improving the real-world performance of any Dojo apps I know of, and I bet the same is true for JQuery users. Reducing the size of the libraries, on the other hand, is still important. Now that we’re all fast enough, it’s time that we stopped beating on this particular drum lest we lose the plot and the JavaScript community continue to subject itself to endless rounds of benchmarketing.

The Chandler Hub also strikes me as a gem hidden in plain sight. Not only is it a great way to share parts of your schedule with others, it’s an amazingly complete Dojo-based, Open Source UI for getting it all done, too. You can run your own Cosmo server (the code that runs Chandler Hub) inside of your department or organization but more than that, you can get the source. If you know Java (or employ someone that does), the Cosmo server is perhaps the easiest-to-hack-on option for an organization needing a flexible, lightweight task and team management option. Given that every organization I’ve ever worked for has struggled with exactly this type of coordination, the availability of source code here is probably going to beget some amazing integrations with bug trackers and the other project and task management systems already rely on. In some ways, despite being almost completely different in scope, Chandler Hub and Plaxo’s kick-butt online features are both brining a level of visibility to different types of activities that cry out for better and deeper integrations with the tools that get used every day to “do the work” or track it in other ways. A few lightweight bridges to MS Project and/or Trac/Redmine would make Cosmo jet fuel for team visibility. I can’t wait.

The Chandler team also told me last week that they’re hard at work on a re-architecture of their python-based desktop client in order improve the performance and startup time and to make the whole system more hackable. Given that the desktop and web clients can speak to the same Cosmo server back-end (which can federate data out to lots of other places to boot), this seems like a promising path forward as the team completes a transition to a more traditional OSS distributed-development approach. Truth be told, I probably won’t give up Thinks for Chandler desktop until performance does improve, but I’m sure gonna be tying my calendars together with Jennifer’s via Chandler Hub ASAP.

Congrats again to the Chandler (and Cosmo and Hub) team(s)!

I’ve had the pleasure of working with Peter both in the Dojo project and at SitePen and his energy and enthusiasm for making Dojo better and helping designers and developers work better together is infectious.

For anyone not familiar with Peter’s work, he’s been instrumental in the creation of the amazing Dojo Campus website (along with the Uxebu chaps) as well as being primary author of many DojoX components. His work in shepherding new contributors through the contributor to committer process is nearly legendary inside the project, and Peter has been a one-man outreach and support machine via the Dojo blog and his endless patience on the forums and IRC (#dojo on irc.freenode.net). I couldn’t be happier about where Dojo is headed under his direction.

There have already been some recurring questions about this transition amongst the committers and on today’s Open Web podcast, so let me quickly recap them here:

Q: Will you still be involved in Dojo?

Absolutely! I’m excited that Pete is taking on the figurehead and “vision thing” duties which is a role that he’s naturally suited to. Part of this transition is about me wanting more time to focus on experimental and edgy stuff that can make a huge difference in how we work with the web and I have no doubt that Peter is the right guy to help us grow the truly open Dojo community even further. He absolutely gets the importance of a truly open community, the need to be conservative about where IP comes from and meet our promises of backwards-compatibility, and how Dojo can make big changes in the lives of application developers and designers. I’m grateful to be have the opportunity to continue working with him on Dojo and will continue to do so in whatever capacity Peter deems appropriate.

Q: Does this change your role at the Foundation?

Nope. I’m still serving as President of the Dojo Foundation. This transition will allow me to also focus more time on ensuring that the Foundation is running well, that a new Board is elected soon, and that the Foundation’s other projects succeed on their own terms. The Foundation has always been about more than just giving Dojo a home, and we’re now looking to expand the umbrella of the Foundation to help nurture other JavaScript and Open Web projects more than ever.

Q: Will you still be doing talks on Dojo?

Yep, I’ll still be out there advocating the Dojo case, but you can expect to see Peter doing more of that over time as well. If you’re planning a conference and are looking for a cogent person to talk about Dojo, Peter is now your go-to guy. I’ve enjoyed having the opportunity to think and talk about where the Open Web is headed, so I’ll also be doing a lot more of that. There are lots of meta-issues that this transition will let me work harder on, so expect more from me there.

My hat’s off to the Dojo community and Peter in particular. The work that has gone into 1.2 and will land in 1.3 and beyond under his direction really is changing the way we view what the web can and should be used for.

Speaking as a member of the OSCON program committee, I’m very happy about the quality of the talks in the web-ish tracks this year. There’s even a Dojo talk – even though for the first time in a long while, I won’t be giving any talks. The inimitable Matthew Russell, author of ORA’s Dojo: TDG will be giving an awesome talk on 2D drawing with Dojo’s GFX system. I know he’s got some awesome demos worked up, so I can’t wait to see the talk. Gavin Doughtie, occasional contributor to the GFX system, is also giving several talks that you’ll find me in. Should be a lot of fun.

On a more macro scale, though, I’ve started to become concerned that “Open Source” as a brand has lost its way. Those who would speak for Open Source have focused narrowly on licensing and have largely ignored the other social processes and artifacts that define what it means to contribute to OSS projects and how those artifacts lead to success or failure of projects, and therefore, of the movement such as it is. There’s a huge disconnect between what the letter of the Open Source law dictates (the licenses) and the social and process constraints that are required to build high-quality, trustable communities that ensure 100 point OSS products, and many businesses have struck on these differences as a way to use the Open Source brand to imply or insinuate that users should trust their products more than is warranted. OSI’s failure to address this brand erosion has had some troubling effects in the small JavaScript corner of the OSS world of late, and I know we’re not alone. OSI has also proven completely impotent in preventing license proliferation, further eroding the Open Source brand. There are, of course, lots of folks who are also concerned about these thing, and so I’m excited to see David Recordon (of OpenID, etc. fame) giving a talk which looks to talk about some of the community aspects. I tend to blow off “community” talks at conferences, but given David’s use of the phrase “Open Web” and his unique perspective, I’ll be interested to see what he says. I’ll also be curious to see if and how any of this is discussed at the FLOSSCON meeting of OSS Foundation leaders tomorrow and Sunday.

If you’ll be in Portland next week, don’t hesitate to join us for the dojo.dinner() on Wed. I’m looking forward to seeing everyone again and talking though the issues. Should be a great time.

Like previous DDD events, the first day will be somewhat contributor-oriented, and many decisions about the direction of the project are likely to get made there. The Monday event will be community focused with tutorials, presentations of new work, time to present your Dojo-based apps, and opportunities for Q&A with the developers who are hacking on the features you use every day.

Sound interesting? Sign up!

I’m incredibly excited about the SitePen Dojo Toolbox AIR app that just launched. I’ve been using early versions for a couple of weeks now, and in that time it has earned a privileged place on my desktop. Being able to make local builds without delving to the command line is something that I’ve wanted to be able to show new Dojo users for years and this tool finally makes it easy. There’s more work to do around configuring the profiles themselves, but the new tool demystifies many of the build configuration options significantly. Having a searchable API viewer available is also a godsend. Huge props to the team that put it together!

Edit: I forgot to note one of my favorite parts of the project, namely that because the Dojo build system is written in JavaScript (thanks to James Burke‘s awesome work), the build system in the Toolbox doesn’t require Java. Instead, SitePen was able to port the few Rhino dependencies in the build tool to work with the native JavaScript engine in AIR. It’s a minor thing, but it speaks to the excellent engineering behind Dojo’s tooling and the power of having actual web-native technologies inside a desktop app.