Census 2: More Than Just A Pretty Graph

December 16, 2008 – 8:59 am

Benchmarks are hard, particularly for complex systems. As a result, the most hotly contested benchmarks tend not to be representative of what makes systems faster for real users. Does another 10% on TPC really matter to most web developers? And should we really pay any attention to how any JS VM does on synthetic language benchmarks?

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.

By alex | Posted in community, dhtml, dojo, javascript, programming | Tagged , , , | Comments (13)

Notes To A Future Self: Getting Productive On WinXP

December 8, 2008 – 2:15 pm

Windows XP is truly a horrid desktop OS, particularly if you’re a programmer. The default install contains roughly nothing useful, and even getting a development environment going requires grabbing the likes of cygwin, Visual Studio, and a zillion patches from Microsoft.

The truly dispiriting thing, though, is how badly cmd.exe still sucks. I fully admit that my personal programming proclivities are not normal, but to be reasonably productive I need a Unix-like shell, a terminal that works (can be resized, has reasonable VT100 emulation, etc.), and the ability to fix the “Caps Lock” key to do the right thing – namely, have it fire the “Ctrl” key instead. This is all relatively straightforward to do on Linux and OS X. Here’s how I got it done with Windows:

Do the MSFT Patch Dance

Make coffee?

Install Cygwin

We’ve all done it a thousand times. This’ll make 1001. It’s kind of comforting that the Cygwin home page hasn’t changed perceptibly in nearly a decade.

Get SharpKeys

Instead of fugly registry hacks, SharpKeys allows you to map the dreaded and useless “Caps Lock” key to something actually useful. If your key-mapping preferences swing some other way, SharpKeys can likely handle that too. Not sure why it’s not built into Windows, frankly.

Set Up Puttycyg

Having cygwin is nice, but having a terrible shell with Cygwin? Not so nice. Enter Puttycyg, a small hack on the venerable Putty SSH client for windows that provides an option to launch a local Cygwin session in lieu of connecting to another system.

Once I extracted it and ensured the Puttycyg directory was in my windows PATH, I created a desktop shortcut to the putty.exe included in the distribution and configured the shortcut (right-click) to read:

"C:\Documents and Settings\slightlyoff\Desktop\puttycyg\putty.exe" -cygterm -

And then set the “Shortcut key:” to be:

Ctrl + Alt + T

Now, whenever I want a fully functional shell from my desktop, I just hit that key combination and it All Works (TM).

By alex | Posted in programming, work | Tagged , , , | Comments (6)

Joining Google

November 23, 2008 – 2:48 pm

Starting next month, I’ll be a Googler.

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.

By alex | Posted in community, dojo, google, opensource, openweb, personal, sitepen, webdev, work | Tagged , , , | Comments (35)

Journey To The Center Of Prop 8

November 1, 2008 – 3:37 pm

Contents after the jump due to the political (and highly contentious) nature of the content.

Read More »

By alex | Posted in personal, politics | Tagged , | Comments (5)

dojofoundation.org Is Up!

October 22, 2008 – 3:26 pm

My warmest thanks and a hearty “congrats!” to the Uxebu crew and Dylan for getting the new dojofoundation.org site up and running:

The new site is important for a couple of reasons. First, it’s a good step in the direction of working to make clear that Dojo-the-javascript-toolkit and Dojo-the-foundation are completely separate entities with different goals and different leadership. The Foundation will take any and all projects that want a good home and are willing to meet the basic criteria that let others trust the code and process behind Foundation projects. It’s been weird that most of the documentation about Foundation policies and procedures has lived on the Toolkit site for so long, and having them be totally separate should help clarify.

Secondly, the Foundation site helps show off the projects which aren’t the toolkit. The Foundation has more than doubled in size in the last year (in terms of projects), and looks set to continue that expansion. That the Toolkit project gets the most attention has been a long-term irritant to nearly everyone involved, and it’s my hope that the Foundation site will help to fix that.

Lastly, the Foundation site is beautiful. Built with the Toolkit and Dojango, the site is a great showcase for the kinds of things that are easy to build with Foundation-sponsored technologies. Nice work everyone!

By alex | Posted in Uncategorized | Tagged , | Comments (0)

Why Are We Even Having This Discussion?

October 17, 2008 – 2:47 pm

Content after the jump due to the public policy nature of the post.

Read More »

By alex | Posted in Uncategorized, blog chatter, javascript | Tagged , , , | Comments (2)

Greg On Licensing

October 13, 2008 – 5:22 pm

Greg Wilkins hits the nail squarely on the head:

At Webtide, we sell developer advice, custom development and production support for jetty and dojo cometd. We don’t expect our clients to buy our services because of some sort of guilt trip from the value they obtain from those projects. We expect our clients to pay for the value add that we give. The software is free under the terms of the apache 2.0 license and we expect no charity or moral obligation in return.

This pretty much sum’s up why most venture-backed Open Source efforts either fail so miserably at building real community or just fail miserably in general. Open Source – to my mind – isn’t some talisman you wave over software to instantly take market share from entrenched players or to instantiate your very own +5 Army of Contributors (with the zealotry bonus) for personal gain. Instead, it’s a great way to distribute software that should already be a commodity at near the cost of reproduction (roughly bupkis) and prevent network effects from ingraining outsized profits to firms whose marginal utility is suspect. If something is still worth paying for, it’s natural to expect that it won’t fare well in the world of free software. Too few people are liable to understand its value to create the virtuous cycle of contribution and use that makes the whole thing work. The great news here is that commercial software isn’t dead at all. It just has to actually be better.

Open Source (and to similar and complementary extent, open standards) helps drive Pareto-efficient allocation of capital in the software business. That may not be a high calling, but it’s a lot easier to justify than living off of monopoly rents for a living, and I take great comfort in knowing that what we do at SitePen adds amazing value (else we wouldn’t make a living at it). As with Greg and WebTide, people pay us for what’s actually scarce: clue, skill, and hard work.

By alex | Posted in Uncategorized | Tagged , | Comments (1)

delegate(), delegate(), delegate()

October 10, 2008 – 4:50 pm

My MBP batteries keep dying after about a year (each). I usually have 2 that I tote around with me, and each tends to be good for 1.5-2hrs of actual work. This means that I tend not to be able to work through a cross-country flight, and particularly not if I need a VM for anything (which is most of the time). I think that if Apple does rev the MBP’s on the 14th, the things I’d pay for boil down to “more memory and much longer battery life”. The 5+ hour flight to TAE then provided a short window to do work in before I retreated to watching episodes of The Colbert Report on my phone. Knowing that i wouldn’t be able to work the whole time, I brought a copy of a great paper on Traits. The paper got me thinking a lot about dojo.declare() and dojo.delegate().

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.

By alex | Posted in dhtml, openweb, programming, webdev | Tagged , , , , | Comments (8)

“Action Oriented Programming”

October 9, 2008 – 9:40 am

It’s good to be back in SF after a pretty hectic week in Boston for Dojo Developer Days and The Ajax Experience. There’s a lot to say about them, which hopefully I’ll get to in a longer post. Our first DDD event under Pete’s excellent leadership was a success and Dojo and SitePen very well represented at the conference.

While in Boston, Gavin and Jill joined a gaggle of Dojo hackers at a dinner ostensibly to mourn my birthday (thanks to Dylan and Pete for organizing!) and in the course of conversation Jill asked something along the lines of:

So why do people get so excited about closures?

Which prompted a several of us to flail and flop gasping the salt flats of analogy like fish out of polite-conversation water. After about 10 minutes of this, Jill succinctly summed it all up in the form of a question:

Oh, so it’s like “action-oriented programming”?

This is perhaps the most insightful and succinct description I have ever heard of what JavaScript is all about.

Update: Jennifer just played this for me and it gets right to the heart of this post: the important part of doing what we do with computers, and more importantly, with the web, is to give the power of Computer Science to real people…and it starts with insights like Jill’s that build a shared way of thinking and talking about the world. It makes me sad that many programmers miss that, but when non-programmers can share in the beauty and power of code, it does a lot to make it all seem worthwhile.

By alex | Posted in javascript, programming, webdev | Tagged , , | Comments (3)

ZendCon Notes

September 19, 2008 – 11:35 am

I gave a talk on Dojo Wednesday at ZendCon, and when I walked into the room for the talk, there was some disorder as the conference center staff were taking out the tables to fit more chairs in. Even with the extra space, the room was totally packed, thanks in large part to the amazing Dojo integration work that the Zend team has done.

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):



By alex | Posted in community, dojo, webdev | Tagged , , , | Comments (4)

Matthew Russell Keeps The Good Stuff Coming

September 16, 2008 – 3:30 pm

Matthew Russell, author of ORA’s “Dojo: The Definitive Guide” now has a companion blog where he’s posting new widgets complete with screencasts to explain them clearly. His awesome first outing includes a neat reflection widget that builds on AOL’s high-performance CDN hosting of Dojo and practices what Dojo preaches about pragmatic progressive enhancement. Awesome stuff!

By alex | Posted in Uncategorized | Tagged , , | Comments (2)

By The Numbers

September 14, 2008 – 12:12 pm

Note: contents of this post is after the jump due to its political nature.

Read More »

By alex | Posted in Uncategorized | Tagged , , , | Comments (6)

Thank Goodness…

September 6, 2008 – 2:55 pm

…for Mark Thoma.

Note: the rest of this post is after the jump due to it’s political nature.

Read More »

By alex | Posted in Uncategorized | Tagged , , | Comments (11)

The Appalling State of Tech Journalism: Reflected in the Chrome

September 2, 2008 – 9:09 pm

Taking a page (or is it a post?) from Brad DeLong’s long-running laments on the state of journalism in general, I have been reading the coverage of the Chrome announcement and keep asking myself “why, oh why, can’t we have better tech journalism?”

Take, for example, ZDNet’s gutter-to-gutter coverage which, I’m afraid, simply ends in the intellectual gutter. Larry Dignan’s piece does the profession no favors by simply recycling the tried-and-true blogger formula for traffic generation:

I know about X, Google did Y, which is clearly *all about* X

The best of this flavor of “story” approaches the quality level of a plausible but objectively outlandish conspiracy theory, often pulling together bits of fact with a healthy dose of wild speculation (journalistically couched as the unfounded and unquestioned opinion of some supposedly credible third party).

ZDNet piles all aboard the loony-bin express with Paula Rooney’s “analysis” piece, helpfully asking the non-question “is this a prelude to Google acquiring Mozilla?”. In what twisted alternate universe would this wild, hair-brained straw-man garner a full ‘graf in a legit online publication, let alone a respected print daily? A small, tiny dig into the strategy of Google’s Mozilla search placement deal and the infrastructure of the Chrome browser would lead anyone (and everyone) to conclude that Google’s interest here is in keeping the browser a viable platform by any means necessary, not that they would ever gain anything by “acquiring” MoCo or MoFo (an even more nutty idea, since it would be difficult for a 501(c)3 organization to transfer resources and assets to a for-profit entity anyway).

The strategic and tactical incoherence continues with the daringly dumb quote:

Larry Dignan of ZDnet suggests that perhaps Google and Mozilla are working together as a tag team to defeat Microsoft’s Internet Explorer, and that Google may perhaps purchase the Mozilla Firefox crew and integrate the two code bases to deliver a kock out punch to Microsoft’s IE. Will Mozilla become Google browser labs? Given the close cooperation of the two projects, it’s more than possible.

Ignoring the incestuous and dubious use of a fellow reporter’s speculation as a source for an article, the idea that the Google would want much (if any) of the Firefox team (or vice versa) beyond those which they already pulled away. It does Google no good to reduce competition in the browser space, and one can imagine that there’s no love lost at Mozilla over Chrome, particularly after Google shunned the Firefox rendering engine, replaced the JavaScript engine, and re-built the entire visual and end-user experience from-scratch with completely different technology (i.e., not XUL). Good sourcing might have fleshed out the idea and perhaps even made a case for the theory, but alas, that seems far too much for ZDNet to produce on deadline. I mean, it’s not like they cover technology for a living…gosh, that’d be embarrassing. Quick tip for the next time they want to write this story: Google just became “Google’s browser labs” after giving Mozilla a good long run at it. They’re still strategically aligned, but Google seems impatient and is likely most interested in having direct leverage in the browser space (first via Gears and now Chrome) instead of the indirect influence they exerted over Firefox when it was still “Plan A”.

The coupe-de-disgrace belongs to PC World, though. After laying out 7 sensible, but “we’re just cribbing this from the press release, really” reasons to like Chrome they proceed to indulge in 7 forehead-slappingly idiotic reasons why you might consider something announced as a Beta to be…well…a beta. It feels kinda dirty just linking to it. Luckily, the PC World crew was able to get it together enough to publish a scoop-free “I played with it for 5 minutes” piece that WaPo wasn’t embarrassed to run, although the “like being there!” aspect really looses it’s punch when anyone can download the beta and, well, be there.

At least with Wired you know you’ll be getting fawning access journalism without the pretense of objectivity, but damnit, it’ll be well written and vaguely cogent.

I won’t even start on the blags. It’s to depressing. I’ll except Ajaxian and Philipp Lenssen here as they added some useful background from the inside perspective and scooped the story (respectively). “Citizen journalism” has a loooong way to go before it earns a place in the 4th estate, though.

Why, oh why, can’t we have better tech journalists?

By alex | Posted in Uncategorized | Tagged , , , , | Comments (10)

The Importance Of Chrome

September 1, 2008 – 4:28 pm

The rumors seem to have been true…the gBrowser is real. And it looks like it will simply be awesome. To my friends who have been toiling on it in deep secrecy for so very long, congratulations. Yes, yes, more to do, blah blah…screw that. You shipped! Huzzah!

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.

By alex | Posted in dhtml, javascript, opensource, openweb | Tagged , , , , | Comments (21)