How to Save the Web
Brendan Eich delivers a vicious smackdown to Microsoft for dissembling their motives regarding ECMAScript 4 (JavaScript 2). In essence, Microsoft is pushing back against ES4, claiming it is unnecessarily complex, while simultaneously touting its own full-blown web development framework (C#, .NET, Silverlight and friends). The reeks of hypocrisy and serves as further proof that Microsoft is continuing to employ its famous “embrace and extend” strategy on the web.
I can’t resist pointing out that, when I made a similar argument for improving web markup, the very same Brendan smacked me down for pragmatic reasons:
jgraham already pointed out the Prisoner’s Dilemma facing browser vendors trying to gain market share. Cooperate with the purity police while IE continues to defect? You lose.
Be that as it may, we’re all on the same side here, and the real question is how to push forward innovation on the web despite the daunting inertia of a billion legacy web browsers, most of which are controlled by a corporate entity that is pursuing its own strategic agenda. Whether we’re talking about better markup or better scripts, we quickly bump up against the “Prisoner’s Dilemma” that Brendan evokes.
I can see two possible solutions. One is a true paradigm shift. If people stop using web browsers as we currently know them in favor of, say, Rich Internet Application platforms like AIR or Prism, there will be an opportunity to deploy superior technologies that break with the past. In this scenario backwards compatibility is nice-to-have but not essential. For example, Google might decide to implement some future generation of Gmail on top of an RIA runtime in order to provide a more compelling user experience. In this case, I could easily see them opting for Mozilla’s open Prism technology rather than Adobe’s or Microsoft’s proprietary stack. If most people end up with Mozilla’s runtime on their machines, strategic control of web technologies would slip from Microsoft’s grasp.
The other option is to out-embrace and out-extend Microsoft. This might involve taking a page out of Adobe’s book by developing an ActiveX for IE that let’s users run ES4 and other goodies without having to convince Microsoft itself to play along. As it transpires, an ActiveX control for the Gecko rendering engine already exists, so there may not be too many technical obstacles to achieving this. Much more of a challenge, of course, is getting the deployment story right so that enough people end up installing the control in their browser.
The sad fact is that cooperating with web standards efforts that threaten the viability of its own strategic web initiatives is simply not in Microsoft’s interest, maddening as this may be. It won’t be easy, but pulling an end run around the Evil Empire and beating them at their own game is probably the only real option. And it’ll be oh so satisfying if we can pull it off.
9 Comments »
Trackback URL RSS feed for comments on this post.
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Check out this wiki page http://wiki.mozilla.org/User:Shaver/ES4_FAQ
ScreamingMonkey is being developed so you can do ES4 in IE.
Comment by Richard Klein — 11/1/2007 @ 9:46 pm
That page isn’t really ready for public consumption, which is why it’s still just hanging off my User:Shaver section, but the ScreamingMonkey stuff was announced by Brendan and others in many places in July: http://www.google.com/search?q=screamingmonkey
Mike
Comment by Mike Shaver — 11/1/2007 @ 9:51 pm
What do think about Google Desktop and the new ability to add its gadgets into iGoogle? Even that types which are able to get things from your desktop - e.g. music players at iGoogle website playing songs from your disk. Isn´t that something like AIR but in the opposite way?
Comment by jilm — 11/1/2007 @ 10:26 pm
Matt: how does my application of the Prisoner’s dilemma to the XHTML utopia conflict with ES4, which is (unlike XHTML vs. HTML) backward compatible, and which (thanks, shaver) has ScreamingMonkey, a back-up plan for IE support (this plan is good for downrev IE in any event) if Microsoft rejects?
I guess you didn’t get the ScreamingMonkey memo. Need to fire my agent :-P.
/be
Comment by Brendan Eich — 11/2/2007 @ 12:17 am
Brendan,
Well, the thing about backwards compatibility is that is becomes irrelevant as soon as people start using the cool new features of ES4, so I still maintain that the barriers are very similar to widespread adoption of XHTML.
But I take full responsibility for punting on ScreamingMonkey. I remember reading about a bunch of monkeys a few months ago but I guess I wasn’t paying close enough attention. Tell your agent they’re off the hook.
Comment by Matt — 11/2/2007 @ 1:05 am
Backward compatibility is not the same as graceful degradation. With HTML5 as proposed by the WHAT-WG, for instance, an input tag with a new type degrades in older browsers to a text field. Not so with XForms in XHTML2.
With JS2/ES4, the C-like syntax simply does not work that way. Instead, new ES4 content must be shipped only to browsers that support ES4. This can be done client- as well as server-side.
User-agent sensing may seem to imply “writing all of your JS code twice”, but it’s not as bad as that. You can buy into ES4 incrementally, annotating APIs for your Ajax library, but not the library code. The API annotations can be conditionally crunched or removed by your server-side setup. The implementation code behind the APIs can be migrated to use ES4 over time, with translation to ES3 handled by a compiler. And code generators (GWT etc.) can target ES4 where it’s supported.
We have been through JS upgrades before, from ES1 to ES3. The web was smaller in degree and content complexity, but nothing is different in kind now. The same techniques still apply. And ScreamingMonkey plus other browsers supporting ES4 natively should, best case, mean near-ubiquitous support within two years.
/be
Comment by Brendan Eich — 11/2/2007 @ 1:31 am
Brendan,
Hey, I’m the guy who supports radical new web technologies, remember? You make a great case for ES4, and I believe that the same approaches could be applied to make XHTML a viability evolutionary path, were we to apply the same level of ingenuity. In fact, I think I might feel another blog post coming on.
Comment by Matt — 11/2/2007 @ 2:13 am
I would be interested to read another blog post regarding the viability of XHTML. Sometimes I get the feeling that one can talk about XHTML in several regards - full adoption, replacing everything: webforms 1.0 with XForms, etc. Or a much more base-level approach: lets just write HTML that is XML compliant–close all your tags, put ending slashes on empty tags, etc. Just this, would be a step in the right direction.
I also don’t understand why the two can’t co-exist. We already have an XForms extension that is nearing completion, SVG is built-in, we can use doc-type and serve pages in various MIME Types, it seems things already do coexist quite nicely, in Firefox.
One rather large obstacle that seems to be holding things back is that IE doesn’t have its MIME types together (application/xml+xhtml not supported). Funny, seems like that is a recurring theme lately, “IE holding back the web…”
I write a lot of internal business web app stuff and XForms has been a tremendously powerful tool. IBM is putting a of stock in it, but get the impression there is resistance, maybe just indifference to it inside Mozilla, and I don’t understand; why can’t we have this wonderful tool right along side the older web forms. Isn’t this the standards-compliant version of “embrace and extend”. You talk about beating MS at their own game, and wanting to do it based on standards, XHTML, XForms, and the lot, strike me as a great starting place. Keep backwards compatibility but add the shiny new goodness, just like the ES4 story.
Anyhow, blog on, I’ll be reading.
-mawrya
Comment by mawrya — 11/2/2007 @ 3:37 am
Matt, you should check out WHAT-WG list threads on saving XML via XHTML5 — Sam Ruby, Henri Sivonen, Anne Van Kesteren are some names to seek.
/be
Comment by Brendan Eich — 11/2/2007 @ 8:52 am