Infrequently Noted

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

Some OSCON Proposal Tips

For the last several years I've been lucky to serve on the OSCON program committee. What that means, basically, is that for a couple of weekends a year I sit down with all the talks that have come in through the "call for participation" process for my track (web stuff) and try to sort out good from bad. Once that's done, we try to identify any holes in the program and fill them to ensure that OSCON really does benefit attendees and that speakers and talks represent the diversity in views and interests of the Open Source world. My personal perspective is that it's the Program Committee's job to zealously guard the quality of the talks since the PC doesn't represent that business side of OSCON, but rather the attendees. I've always been impressed with how hands-off ORA is about this part of the process, ensuring that everyone gets a fair shake (as far as the PC is concerned). Part of that responsibility is to make sure that when you go you're not marketed to outside of the clearly labeled exhibitor booths. Content is content. Marketing is marketing. They both have a place, but that place is clearly marked and that's one of the ways that we try to keep OSCON good.

As it happens, this weekend is one of those sift-through-hundreds-of-talks weekends for me. The advice I'm about to give is therefore top of mind. Other PC members do things differently and have a different perspective, but generally the list of "do's" and "don'ts" that are listed on the talk submission page are a good guide. I do regret not having done this after last year's grading, but better late than never. I'll try to link back to this post next year (if I'm still lucky enough to serve on the PC) to give fair warning. Lastly, before I get into it, be assured that these guidelines don't talk about any single proposal. They're from persistent patterns I've seen over the years. Here goes:

In some sense, I hope that the truly bogus corporate-drone-submitted proposals don't get much better. They're easy to spot now, and their horrible quality makes them simple to filter out. Instead, I hope that folks who might otherwise be on the line find this list useful as a way to push them over the threshold.

My personal thanks go out to everyone who reads this blog and submitted talks this year. The quality in the web track is great, and many important topics are represented in the submissions that reflect how important the web is to Open Source (and vice versa).

...and the waiting starts

In Venezuela.

You might want to watch this Frontline episode for background.


After trying nearly a zillion different shells on Windows, I'm back to Cygterm, in part because it makes cygwin happy and because I've just come to accept that some stuff will always require cmd.exe. Windows just sucks like that. On the upside, the Wombat VIM theme rocks my world.

Mark Thoma: "Tax Cuts Won't Build Schools"

Pro-cyclical arguments (the same ones that got us into this mess) are saying that we shouldn't begin public works projects because they might take a while. Mark Thoma shreds these them to little tiny bits.

I particularly enjoy how he notes that we've run a test of the "tax cuts solve everything" theory and how it's pretty clear that it failed. Miserably. While ballooning the deficit with nothing to show for it.

WebKit == Mobile

With the Pre/Mojo announcement, it's becoming clear that WebKit has mobile all sewn up. It bears listing who's betting on WebKit and where:

iPhone, Safari
Android, Chrome
Series 60 browser
AIR web runtime

From deep integration with the platform to being the platform, WebKit in various forms is how nearly every credible smartphone now "does" the web. The major outliers here are the WinCE devices, Blackberry, and whatever Sony's doing this week, but the writing is on the wall for them too. Mobile IE is a joke and the Blackberry succeeds in spite of its web experience. iPhone, Android, and Pre have raised the bar. The sucky-web center will not hold.

For a sizable chunk of the mobile browsers that a web developer would like to target today, that means that WebKit == Mobile. As predicted, the mobile world has beaten the desktop to the web of the future. It doesn't hurt that WebKit is making deep inroads into the desktop, either....but then you could reasonably assume that they pay me to say that.

So what does a WebKit-only world look like? And how portable are our desktop-web skills and tools? I did a quick set of experiments this past weekend to see how much of Dojo you'd still need and what we could leave behind. The results are encouraging. The headline numbers for dojo.js are roughly:

ShrinkSafe +gzip
Standard Build 79K 27K
webkitMobile=true 56K 20K
Savings 23K (29%) 7K (26%)

You can grab a copy of this pre-1.3.0 version here (webkitMobile.dojo.js).

The big size wins (in decreasing order) were:

  1. Moving to a QSA-only version of dojo.query()
  2. Being able to use intrinsics for dojo.forEach, etc.
  3. Dropping IE and FF-specific rendering, XHR, and style hacks
  4. Using a common closure wrapper for the entire core

And there's even more fruit on the vine. I think without too much more work I'll be able to drop the current animation system in favor of pure CSS animations and can significantly simplify the XHR code which doesn't do the straightforward thing to avoid terrible memory leaks on IE and very old versions of FF.

All of this points to where we could be if the browsers just got collectively awesome all of a sudden. That's the good news. The downside is that still leaves a lot of janktastic spec mistakes to be worked around at nearly every level of the platform. This experiment suggests that there is still a price to be paid just to get the platform to a usable state. If we look at the APIs of Dojo, Prototype, or jQuery as a set of suggestions for the APIs that the web should expose, then it becomes pretty clear that we've still got a long long way to go. But we can do at least 30% better in the short run, and I'm very glad of that.

My friends over at SitePen beat me to the punch on my own patches, but that's how it goes sometimes. Props to them for that.

Older Posts

Newer Posts