Infrequently Noted

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

Things the W3C Should Stop Doing

This is a quick thought as I'm working on something much longer (and hopefully more interesting) to be published in the next week or so. Also, I just want to re-iterate that what's said here are my own thoughts and not those of Google unless expressly stated otherwise.

I've been arguing -- mostly over beers -- for the last year or so that the W3C needs to find a ways to re-focus on the needs of the constituencies that give it credibility; namely web developers and browser vendors. This tends to fall on frustrated W3C staffer ears as individuals might agree but the organization feels the effects of its failures not as a question about how to re-focus around a credible mission but as a short-run funding shortfall. I'm excited that the new Community Groups have the potential to help fix some of this by allowing a freer flow of ideas and a more representative expressions of demand, but there's the lingering pay-for-play issue that I think is liable to drag the organization back to the status-quo as soon as the excitement and newness of Community Groups wear off.

Now, let me say clearly up front that I don't think that standards bodies are charities, nor should they be. People join (in the case of the W3C, "people" == "companies", an equivalence that works as US legal fiction but never in the real world) because they're expressing their economic interests in agreement on thorny, market-focused issues. The W3C, as an organ, has grown out of an IETF alternative into a critical mediator in the flow of ideas and technology in the web ecosystem. When it fails, we're starved of progress because nothing else can easily grow in its place. Bless Hixie and the WHATWG for trying, but the W3C sits on fertile spec and patent rich land. It's tough growing in the rocky craigs, particularly without a patent policy.

So, in the spirit of reform, not revolution, I have a proposal, complete with Swiftian modesty:

At this year's TPAC, it should be agreed that the W3C will divest itself of any and all Semantic Web, RDF, XML, Web Services, and Java related activities. SVG can be saved, but only if it re-charters to drop all XML dependencies in the next version.

Where should these specs and member organizations go to get their itches scratched? I'm not sure it matters, although it seems likely that OASIS wouldn't mind being the go-to place for XML. And there's always ECMA, or IETF, or ISO, get the idea.

Why do such a drastic thing?

Well, it's not that drastic, really. The SemWeb folks use the term "web" in a hopeful, forward looking way that nobody else does. Their technology is showing promise inside firewalls but their work has near zero relationship to the actual, messy web we swim in every day. The result is that their narrow constituency isn't the one that animates whatever legitimacy the W3C might enjoy, and therefore their influence in the W3C is out of all proportion to their organizational and web-wide value. Sir Tim's belief in their goal is noble, but to use the suffix "web" on it today is simply wishful thinking. And things that don't have anything to do with the web probably don't belong at the W3C. Besides, the W3C imprimatur doesn't help these specs and groups as much as their advocates might think -- standards bodies aren't venues for creating the future after all, only for cleaning it up in response to the messy, explosive process of market-driven evolution. Anyway, being endlessly frustrated that the entire web hasn't changed to accomodate some new model even though it has the phrase "web" in the name can't be fun. Technologies need to find their success where they really do fit and distributed extensibility and semantics might be valuable...but it hasn't been to the web yet. It needs to go.

As for XML, well, it won the enterprise and lost the web. That's still success, but it's not the web.

Rinse, repeat for RDF, Web Services, and Java.

What would that leave us with? CSS, DOM & JS APIs, HTML, a11y, i18n, and all the other stuff that has legs out on the public web. More to the point, it would have the beneficial effect of re-focusing the organization around getting HTML5 done, getting DOM APIs done that don't suck for JavaScript on the altar of IDL "language neutrality", etc.

Organizationally, it would leave the W3C in a much leaner, more focused place. It's much easier to build a focused constituency and membership, and the lower cost structure would only help the organization weather hard times. I have high hopes that it can be brutally effective again...but to get there, it needs to focus, and focus is the process of ignoring things. The time has come for the W3C to grab the mantle of the web, shake off its self-doubt, and move to a place where doing good isn't measured by numbers of specs and activities, but by impact for web developers.

Why "class" Doesn't Mean What You Think It Means

There's a lot of "don't turn it into Java!" in the comments on my last post, and I feel it needs a response -- and not because I think there's anything to like about Java's class or type systems (perhaps that they exist at all? I'm torn on even that).

Lets look at some possible code and walk through how it relates to today's equivalent JS:

module widgets {
  // ...

export class DropDownButton extends Widget { constructor(attributes) { super(attributes); this.buildUI(); }

buildUI() { this.domNode.onclick = (e) -> { // ... }; } } }

Ignoring the semantic improvements of Harmony modules over the module patterns we're using today, we can see a pretty straight-up de-sugaring of that to today's JS with an emphasis on the many and varied uses of the word function:

var widgets = (function(global) {
  // ...

function DropDownButton(attributes) {, attributes); this.buildUI(); }

DropDownButton.prototype = Object.create(Widget.prototype, { constructor: { value: DropDownButton }, buildUI: { value: function(e) { this.domNode.onclick = function(e) { // ... } } } }); })(this);

What you should take away from this isn't that we're turning JS into Java, it's that we're making it easier to read, AND THAT'S ALL. Once more for effect: what class means in ES6 is function. Or at least one of the things you currently do with function.

Better yet, we're blessing a single pattern which you can use with old-style classes just as easily as you do today. I'll leave it as an exercise for you to name all the different class patterns and systems that do nearly the same thing in slightly incompatible ways today. It's a very long list.

If you like JS, and you like functions + prototypes (I do!), you have nothing to fear from the sugar we're adding in ES6.

Update: A lunchtime conversation here at DojoConf today reminded me of perhaps the largest thing that this new system doesn't do; aren't tied to a Java-like type system. Many of the conjoined fears of Java come from the very real pain created by a strict, nominal type system, and nobody in the committee is proposing a mistake like that -- least of all me.

Older Posts

Newer Posts