How to Save the Web, Part Two
I’ve had some time to reflect on my recent musings about how to push forward innovation on the web without ceding dominance to closed, proprietary technologies. Several people pointed out that I was embarrassingly uninformed with regard to ECMAScript 4 support in Internet Explorer. The ScreamingMonkey project has been around for a while with the aim of achieving exactly that. And I’m so open-minded that I still think this is a fantastic idea, even though it apparently isn’t mine.
I read more closely what the Microsoft people have to say about the situation, and I’m actually finding myself sympathetic to both sides of the argument. Microsoft’s line is that a substantially revised JavaScript language doesn’t make much sense since there are already mature languages like Python and Ruby that could serve our second-generation web scripting needs. Backwards compatibility is all well and good, but people are still going to be reluctant to use new language features if they aren’t widely supported by browser vendors. I’m not a language designer so I can’t speak definitively about the challenges of supporting both ES3 and ES4 syntaxes, but this is bound to introduce a fair amount of complexity and redundancy into the scripting engine implementation. Simply adding Python support might be a more sensible path.
On the other hand, JavaScript has amazing mindshare on the web, and from a pure marketing standpoint it may be easier to achieve widespread usage of modern scripting constructs if they are promoted under the JavaScript brand. Moreover, Brendan has undoubtedly forgotten more about language design than I’ll ever know, and he is obviously convinced that ES4 will provide a smoother transition path than an entirely new language like Python. On a strategic level, Microsoft considers JavaScript to be a Mozilla technology, explaining why the former is eager to jettison it while the latter wants to see it reinvigorated. That’s how the market works (and works well).
The other pillar of the future web (and another favorite topic here on Peer Pressure) is markup. The shortcomings of HTML for application development (as opposed to document representation) are clear. At the same time, I find it hard to get too enthusiastic about XUL. This may be a case of familiarity breeding contempt, but in my experience XUL user interfaces are more functional than attractive. I’m not crazy about certain XUL features like XUL Templates, whose syntax strikes me as obscure. There are some very cool XUL-related technologies like XBL (if it had better error reporting), but the bottom line is that the idea of XUL on the web hasn’t gained much traction.
In the long term, someone like WHATWG may address HTML’s shortcomings as a language for app development. But as with the scripting debate, it’s worth considering whether there isn’t an existing language that could fit the bill. The obvious choice is Adobe’s MXML, which is used by Flex to build user interfaces. Whereas XUL UIs tend to be rather drab, the flashier Flex demos I’ve seen had me positively drooling. Adobe has already open sourced Flex, and it has donated its open source Tamarin virtual machine to the Mozilla project (something that still warms my heart every time I think about it). I’ve already blogged about Brendan blogging about a potential harmonization of XUL and MXML. And while Flex is still a relatively recent innovation, Flash continues to be astonishingly successful, and it’s reasonable to expect that Flex will be able to leverage to great effect the huge Flash development community and near ubiquitous Flash runtime.
From Mozilla’s perspective I can’t really see any downside to this scenario. All other considerations aside, it would reduce the number of wholly owned technologies that they have to maintain, leaving more bandwidth to deal with innovation in other areas (Mozilla 2, Prism, etc.). XUL would need to supported for some time to come as the language of Firefox’s chrome and that of its hundreds of third-party extensions. But this can probably be bridged with a fairly straightforward mapping of XUL tags into their MXML equivalents. More to the point is the question of what Adobe might gain from this approach.
A few months ago I gave a talk about web application development and mentioned the oft-cited statistic that the Flash runtime is available on 99% of web browsers. Afterwards, one of the other speakers pulled me aside and explain that this is due primarily to the fact that some crufty old version of Internet Explorer came preinstalled with an equally old and crufty version of Flash. The number of machines with the newest version of Flash installed, he claimed, is far smaller. I haven’t confirmed this, but it has the ring of truth to it.
Adobe has staged one strategic coup after another since its brilliant acquisition of Macromedia two years ago, but it still lacks one vital strategic asset: a killer app. Bundling Firefox with a future, open source Flash would fill this gap and have a salutary effect similar to the aforementioned IE bundle (though admittedly on a smaller scale). This is particularly true because Firefox has a great upgrade story, virtually ensuring that users stay current with new versions. In addition, Adobe and Mozilla are facing a similar challenge from Microsoft’s Silverlight and will be better able to counter it if they combine forces.
For all I know (and I don’t), discussions along these lines are already underway. It’s intriguing to note that, were this to take place, the distinction between Prism and AIR (both of which would be using Tamarin, Flex and SQLite) would boil down to choice between the Gecko and Webkit rendering engines. And that, many would contend, would also be a good thing.
19 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>
I don’t think XUL and XBL are nearly as related as you make them out to be. I like XUL. It provides all the little widgets that HTML should, but can’t because it started as a document markup and not an application markup.
I’ve always been more amazed that XBL hasn’t caught on though. All those javascript toolkits you’re seeing spring up on the web seem much easier to create and distribute via bindings than the way they are. You want a menu, you take your UL list and attach it to a menu binding. I don’t care if the binding is written in HTML or XUL of Flex or anything. I just hate having to resort to adding six different javascript files for it to work.
Comment by DigDug — 11/5/2007 @ 7:43 pm
I agree on both counts. I sort of see XBL as part of the “XUL family”, which is why I brought it up in this context, but you’re right that the relationship is more notional than technical. And XBL certainly has a stronger claim to being a unique technology whatever the eventual winner(s) of the markup wars turn(s) out to be. The main problem I have encountered (as I mentioned) is that the smallest syntax error can prevent the binding from functioning with no feedback whatsoever to the developer.
Hopefully the standardization effort around XBL 2.0 will fix any technical issues and lead to broader adoption.
Comment by Matt — 11/5/2007 @ 8:20 pm
Python as implemented in C-Python is not going to be a new language for browsers to support, and it would not address the goals of ES4 that are based on real problems in ES3. This is not exclusively about Python or in praise of ES3. Let’s review the facts:
1. ES3 is mandatory and not going away, on the web and in browsers.
2. Multiple VMs are simply not affordable in browsers that have to be downloadably small, and anyway in mobile browsers. Code footprint, both direct in terms of two runtimes, and indirect (problems such as global cycle collection to avoid leaks cost too much), will blow the budget.
3. Web developers know ES3, they should be able to migrate to ES4 at lower cost than learning two languages and how they bridge together — not to mention how to standardize that bridge among browser vendors.
Long-term, there will be multi-language VMs in browsers (and routers!). So we are investing in IronMonkey for Tamarin. But not short-term, and anyway JavaScript will be the default basically forever. It will be the only, not just the default, on small browsers. That’s why we are evolving it.
/be
Comment by Brendan Eich — 11/5/2007 @ 10:07 pm
By “Longer-term, there will be multi-language VMs in browsers”, I mean Tamarin supporting ES4, IronPython, IronRuby, etc. — or the .NET CLR. Not multiple VMs of course (see point 2). Sorry if that was unclear.
/be
Comment by Brendan Eich — 11/5/2007 @ 10:10 pm
One more thing: don’t be naive about Microsoft pushing Python or Ruby (Iron-fortified!) as successors to JS — they’ve never identified those, and the performance isn’t there yet. What they seem to be hinting at, and what they explicitly chose to demo (search for “mix07 chess demo”) vs. JScript to show it up, is C#. Yeah, that sounds more like a new, bigger, incompatible language to supplant JS, don’t you think?
/be
Comment by Brendan Eich — 11/5/2007 @ 10:24 pm
Brendan - You make a strong case for retaining JavaScript as the web’s primary scripting language. But how do you respond to those who say that the deep changes in ES4 (e.g. new syntax for declaring structured types) brings many of the costs that an entirely distinct second language would? Should we therefore concentrate on fixing the real pain points in JS since cases where full-blown ES4 support is feasible will also be amenable to use of Python or Ruby? I think the new features planned for ES4 are fantastic but I can also understand the point of view that argues for limiting the scope of JS’s evolution.
Comment by Matt — 11/5/2007 @ 10:35 pm
But yeah, the idea of supplanting JS with C# (and by implication large swaths of the .NET framework) is a lot more farfetched.
Comment by Matt — 11/5/2007 @ 10:44 pm
Regarding Flash Player penetration, Flash Player 9 is in the 90s for sure!
http://www.adobe.com/products/player_census/flashplayer/version_penetration.html
Adobe is full-force behind Flex/MXML and advancing it at a rapid, backwards-compatible pace. Mozilla seems to be waffling on XUL.
You know, the Flash Player story is really amazing to look at in all of this. Flash Player 9 has two VMs in it, AVM1 (ActionScript 2 and earlier) and AVM2 (ActionScript 3+). Flash content going back to the earliest days is still backwards compatible with Flash Player 9!
Will all those hundreds of Firefox Add-Ons still work with Mozilla 2? Maybe thats why they are so hot-n-heavy on the Open Web as a platform. (Translated means HTML/CSS only)
Comment by enefekt — 11/5/2007 @ 11:06 pm
Matt, you seem to be repeating your parallel of Python or Ruby with ES4, but that misses many things in ES4 not in either Python or Ruby:
* optional type annotations
* type parameters
* structural types
* multimethods (coming in py3k, iirc)
And again, a new 2nd language is not an option.
As for the idea that extending ES3 to ES4 somehow changes the language to a different language, you are either arguing against the compatibility we are already demonstrating in the Reference Implementation, or you’re arguing about the “mood” or “feel” of the language.
But look, people already use latent types in JS, and Ajax libraries such as MochiKit even do some structural type (”shape”) testing (see MochiKit’s Base.isArrayLike). This is common, it is inherent in latent schemas for JSON flying around the web today. It should be formalized soundly, and that is what we have attempted to do with structural types. Again, there is no comparison to existing ES3 or similar dynamic languages.
/be
Comment by Brendan Eich — 11/6/2007 @ 12:41 am
enefekt: Mozilla 2 gives us a chance to break API compatibility, but we’re mainly focused on C++ API compatibility, since that lets us deCOMtaminate. Firefox addons may need to be reworked even from Firefox 2 to 3 as you probably know. But in practice this is not a problem, and we are not so suicidal or free to fiddle gratuitously that we would break out most critical platform.
I know the AVM developers well, and they did not want to ship two VMs. They indeed suffered a code footprint hit, but fortunately they do share one memory manager (MMgc). They admit to interop bugs between the two VMs, and aspire to get everything mapped via compiler versioning onto Tamarin.
So that’s a counterexample. Thanks for pointing it out ;-).
/be
Comment by Brendan Eich — 11/6/2007 @ 12:46 am
Your use of "simply" is comic. Where is the runtime and VM that runs both Python and ECMAScript 3 scripts?
The whole "Why evolve JS, just switch to MyFavoriteLanguage" strawman is silly. By all means join a standards body and propose a new standard scripting language for Web browsers, otherwise it’s armchair fantasy.
Comment by skierpage — 11/6/2007 @ 12:50 am
Brendan,
I’m not saying that JavaScript 2 is a bad idea. As someone who codes in JavaScript regularly, I’ve been excited by the prospect since I saw your original JS2 slide deck.
I’m just saying that I can understand the point of view that argues for pushing Python or whatever. After all, it’s at least somewhat controversial whether we need structural types, type annotations, etc. Since I basically accused MS of killing the web in my previous post, I felt like I should clarify.
That said, you’re right to point out that MS is promoting a heavyweight beast in .NET, which is far less defensible.
Comment by Matt — 11/6/2007 @ 1:10 am
It’s my understanding that both the Microsoft VM and Tamarin are slated to support both languages and others.
Hey, my favorite language is C++ and I’m not arguing that we make that the lingua franca of the web.
Promoting a language just because you have a soft spot for it is silly, but I don’t see why the idea of integrating some existing more modern scripting language into browsers is so absurd.
Comment by Matt — 11/6/2007 @ 1:17 am
Silverlight supporting IronPython and IronRuby in 1.1 is good for drawing developer interest away from Flash. It’s not quite as real as “Python” (meaning C-Python) being an alternative language for web scripting. The latter (or “Ruby”, or Ada98…) is a ton of work that would have to be done in the runtime and all the browsers that embed it.
IronPython uses the .NET framework classes, WPF or whatever’s going these days. That’s not quite the same as the C-Python standard library, as far as I can tell.
Anyway, it’s years too soon to plan on any second language supported on a common VM to the extent that you could use it instead of JS. Many years. It’s like planning on replacing C++ soon with some “managed” version or other language (D). Unreal, in a word.
/be
Comment by Brendan Eich — 11/6/2007 @ 4:31 am
Brendan: To me the main point is that we have a Flash Player that works great and is backwards compatible. I’m sure there are some use-cases where the two VMs need to interoperate, but I have only run into one so far, and use of LocalConnection has worked just fine to communicate between the two.
Comment by enefekt — 11/6/2007 @ 1:55 pm
enefekt: great, nothing against the Flash 9 pragmatic decision to ship AVMs 1 and 2 — as I noted this doesn’t fit on Mobile targets, so FlashLite is just 1, and my understanding is that any future Flash for mobile will be an evolution of Tamarin that handles both AS2 and AS3 content.
Again, there’s not enough room for two default “JS” VMs on all target platforms, and ES4 doesn’t require any such thing.
/be
Comment by Brendan Eich — 11/6/2007 @ 5:49 pm
Brendan: The Nokia N800 runs a complete version of Flash Player 9. Adobe is talking more about “device convergence” (http://aralbalkan.com/1072) with Flash Player 10, so you’re probably right that they’ll try and optimize that further.
I am not making any negative comments on ES4, or arguments suggesting separate ES3/ES4 VMs are a good idea. Just saying that I’m enjoying many of the benefits of ECMAScript 4 right now (And a user-interface markup language), in my day-to-day development targeting Flash Player, which runs on multiple browsers and platforms, and can interoperate very well with JavaScript. Not talking about the future, but right now.
I apologize, don’t mean to be gushing so much on Flex/ActionScript, but I figured since it was brought up in the post it was relevant.
Comment by enefekt — 11/6/2007 @ 6:16 pm
Enefekt - actually I wanted to emphasize the Flex angle in my post, so it’s nice to have at least someone bring it up in the comments. Perhaps I should have called my post “Should Mozilla Drop XUL for MXML?”. >:-)
Comment by Matt — 11/6/2007 @ 6:28 pm
I recommend taking a look at http://jnext.org which uses existing technologies to achieve native extensions to JavaScript. It is cross platform, cross browser, and can be easily extended using any language.
Comment by amnon — 11/7/2007 @ 6:25 pm