Parts of EcmaScript 4 deemed unsound for the Web

This was the conclusion of an EcmaScript meeting in Oslo last month. Specifically, as Brendan Eich explains, three features – packages, namespaces and early binding – were considered too heavyweight unsuitable for a browser scripting language. Here is Eich’s “Executive summary”:

The committee has resolved in favor of these tasks and conclusions:

1. Focus work on ES3.1 with full collaboration of all parties, and target two interoperable implementations by early next year.

2. Collaborate on the next step beyond ES3.1, which will include syntactic extensions but which will be more modest than ES4 in both semantic and syntactic innovation.

3. Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony.

4. Other goals and ideas from ES4 are being rephrased to keep consensus in the committee; these include a notion of classes based on existing ES3 concepts combined with proposed ES3.1 extensions.

This means that the evolution of JavaScript is now on a new path, focused for now on a more modest enhancement to the language called EcmaScript 3.1.

Given how loudly Eich protested about EcmaScript 3.1 last October, it is a surprising turn of events. Was Eich convinced by the arguments of Microsoft and Yahoo in support of a more lightweight JavaScript?

What this means is that JavaScript 2.0 won’t happen as previously envisaged. John Resig:

… you can forget a lot of what you learned about ECMAScript 4, previously. Many of the complicated concepts contained in the language have been tossed. Instead there is a considerable amount of effort going in to making sure that new features will be easily duplicable through other means.

Eich and Resig are keen to stress that JavaScript will still be a highly capable language. Still, the obvious conclusion is that this will be good for plug-ins which support more powerful languages: Adobe Flash, Microsoft Silverlight, Sun Java or Java/FX. Personally I’m disappointed.

It is also presenting Adobe with a tricky problem, as it implemented much of an earlier specification for EcmaScript 4 in ActionScript 3. Rather than being a standard language, as Adobe had planned, it looks like this will now be more of an Adobe language. I doubt this will have much practical impact on developers.

PS Brendan Eich has commented below.

Detailed article on Microsoft’s Midori published

The Software Development Times has an in-depth look at Midori by David Worthington, based on “internal Microsoft documents”:

SD Times has viewed internal Microsoft documents that outline Midori’s proposed design, which is Internet centric and predicated on the prevalence of connected systems.

Recommended if you are interested in what Microsoft is contemplating for a future OS. Note that there’s no official word on whether this is more than just another research project.

Technorati tags: , ,

Silverlight 2 threading issues, Quickstarts not working

I’ve been working on a Silverlight tutorial involving reading an RSS feed. Silverlight has a SyndicationFeed class which is meant to make this easy – as Microsoft’s Scott Barnes enthuses here.

It is handy, but I discovered that the Quickstart Barnes refers to does not work in Silverlight 2 Beta 2. The Quickstart section on Silverlight.net needs some work. Even if you get to this Quickstart via the link for Silverlight 2 Beta 2 examples on this page, it is soon apparent that it is actually for Silverlight 2 Beta 1. Click the Run It button and you’ll see that it asks for the older runtime.

The code doesn’t work in Beta 2 either; and as so often with thread-y stuff, it’s not immediately clear what’s going wrong. I got a blank page and the following message in the Debug output window in Visual Studio:

A first chance exception of type ‘System.UnauthorizedAccessException’ occurred in mscorlib.dll

In situations like this I recommend breaking on all CLR exceptions (Debug – Exceptions – check the Thrown box for Common Language Runtime exceptions in Visual Studio). Run again; and this time Visual Studio stops on the line which updates a Silverlight TextBlock:

feedcontent.Text += "* " + item.Title.Text + Environment.NewLine

with the message “Invalid cross-thread access”:

Rooting about a bit, I found this post from Karen Corby on changes in Silverlight 2 Beta 2:

HttpWebRequest’s delegates are called on a new non-UI thread.

  • Delegates were previously always called on the UI thread.
  • You must invoke back on to the UI thread if the data you’re retrieving will be consumed by a UI element.
  • For an example, see the updated networking post series (part one).

What this means is that you have two doses of asynchronous coding to think about if you use HttpWebRequest. First, the request itself; and second, in the code you write for the response handler if it needs to update the UI – which in most cases it will.

The example referenced by Corby shows a neat solution using a SynchronizationContext object, or you can use the Dispatcher class as explained by Wilco Bauwer here – he also draws attention to locking issues. See also Shawn Wildermuth’s post though note that CheckAccess is available despite what is said here.

This adds a significant dose of complexity to Silverlight coding. I’m not sure if any of this will change again in the final release.

I also noticed that VB coders are not well served by the Silverlight examples out there, which are overwhelmingly C#. Looks like this is the language of choice if you want an easy life.