Ozzie: Silverlight Supports AJAX...To a Point

The question of how much support Microsoft intends to give JavaScript as a Web development language became murkier yesterday, perhaps inadvertently, when a statement made by the company's chief software architect, Ray Ozzie, was cited out of context by press sources. The citation by itself made it appear that Silverlight, Microsoft's new cross-platform runtime environment for Web applications, would at some point be competing with AJAX as though that technology were exclusively Google's.

The comment in question is as follows: "We're announcing today that we're bringing .NET technology together with Silverlight, and that Silverlight is being transformed into an amazingly powerful cross-platform extension to our entire .NET development and design environment, specifically factored to run in a browser. The Web over the last years has been mostly about AJAX, about increasing the richness of the user experience through the magic of DHTML, and clever browser hackery. But AJAX development has its limitations, and certainly there are better languages than JavaScript to use for many of the sophisticated apps that developers want to build. In this respect, Silverlight changes the game by giving you a new choice for developing incredibly sophisticated, rich Internet applications in the language of your choice."

That casting of AJAX in an apparently negative connotation led Computer Business Review this morning to interpret Ozzie's speech as "minor back-pedaling on the notion of software as services."

ASP.NET AJAX is Microsoft's implementation of Asynchronous JavaScript, which is code that can be distributed over the Web using HTTP and run on the client side, with the browser providing a kind of transport conduit. In Microsoft's case, the JavaScript code is managed by the .NET runtime module, rather than the JavaScript virtual machine that has gotten Internet Explorer into so much trouble in the past.

The problem may have been with Ozzie's choice of words, or the choice of his speechwriter - specifically, juxtaposing AJAX with "clever browser hackery," then saying JavaScript "has its limitations" and pronouncing that better languages exist. (There's also this curious new permutation of the word "factor" as a verb that we've only seen within the last two weeks from Microsoft representatives.) In recent interviews, including with BetaNews, Microsoft product managers and developers have characterized AJAX and JavaScript as a familiar, functional language that will bring Web developers into the realm of writing for Microsoft's managed code platform. But they've also made it clear that, from there, they'd like developers to move from the familiar surroundings of JavaScript, into what they describe as a more powerful, functional, and capable delivery mechanism.

Often that mechanism involves C#, Microsoft's implementation of a more dynamically object-oriented C language than C++, yet a language that has typically been described as foreign to Web developers, both conceptually and syntactically. In the past, Microsoft has been criticized for trying to horde Web developers into Visual Studio, an environment originally constructed around programming applications software. The Expression Studio suite was created, Microsoft product managers have said, to address this issue and to offer an environment more familiar to the Web development culture.

Yet if JavaScript is to be merely a waypoint in the migration to what Ozzie calls a "first-class" environment, Silverlight's own developers don't appear to have received that memo. Despite demonstrations of using more applications-programming-centric languages in Web contexts this week at MIX '07, despite images of Silverlight applications being played over and during Ozzie's speech, and despite Ozzie's reference to .NET as offering Web developers "a new choice," all eight of Microsoft's Silverlight gallery demos utilize functionality based in AJAX - a fact which should, as long as it's not "clever browser hackery," make the company's ASP.NET AJAX team proud.

Ozzie also spoke about "enhancing Silverlight" and "transforming Silverlight" into a more capable runtime environment for the new class of rich Internet applications (RIA). For some who only first heard about Silverlight two weeks ago, the notion that it needed transformation may have seemed premature.

But others will recall that Silverlight is (or will be) the commercial culmination of the Windows Presentation Foundation/Everywhere (WPF/E) project, which has been in the works for at least two years. If there is any single important transformation to that project going on now, it's the devotion of new energy and resources toward a recently discovered concept called the Dynamic Language Runtime (DLR). Currently, it's described as an extension to the .NET Common Language Runtime (CLR), though designed this time to be implemented in Silverlight - whose runtime may use a subset of .NET.

In a recent MSDN Channel 9 podcast interview conducted by former legendary Byte magazine editor Jon Udell, with Microsoft's John Lam, who created the RubyCLR implementation of the Ruby language for .NET, Lam describes the DLR project as having emerged from Microsoft's experimental implementation of the popular Python scripting language, which became its formal version of IronPython. The project led Microsoft to understand and even embrace the need among Web developers, Lam described, for more lightweight and versatile hosting support for so-called dynamic languages such as Ruby and Python.

What differentiates a dynamic language from a static language, Lam described, is how it manages objects in memory: In a static development language such as C++ or C#, objects are memory constructs that are defined within the explicit context of the application at hand. They are classes that are well defined and rigidly typed - they have to be, or else the compiler won't be able to produce executable code that enables these objects.

But in a dynamic language, bits and pieces of code seem to "happen" - or rather, they are brought into the context of the Web application and executed as necessary. Lam spoke of how the DLR creates so-called dynamic methods: functional elements of dynamically instantiated objects that come into being as necessary, get used, and get automatically cleared by the DLR's internal garbage collector (GC).

There are four languages now that the DLR supports, with perhaps more on the way, Lam said. Besides IronPython and Ruby (no longer tied to RubyCLR), there's a Web edition of Visual Basic...and there's managed JavaScript, one of the big four.

So from Lam's perspective, AJAX isn't transitional at all - not a way to bring developers into a broader choice of bigger, bolder, more rigidly-typed constructs, as Ray Ozzie's comments are being interpreted. Instead, there seems to be a place for dynamic languages and a place for static languages, and regardless of the fact that Microsoft tends to earn more revenue selling the latter than in giving away the former, from a Web developer's perspective, ne'er the twain shall meet.


Update ribbon (small)

2:08 pm May 1, 2007 - This afternoon, a spokesperson for Microsoft gave the following comment to BetaNews, in response to our request for a clarification of Ray Ozzie's statements yesterday:

ASP.NET AJAX and Silverlight are designed to be complementary technologies. In the broader sense, Silverlight can talk to any AJAX application, both client and server-side. In addition to this, ASP.NET AJAX can be used to control Silverlight based visualization of data, or delivery of rich experiences. Examples might include mapping applications, or video playback with rich presentation.

ASP.NET AJAX and Silverlight at final release will also benefit from being a fully supported technology from Microsoft, with the benefits of 24/7 technical support and the breadth support of the Microsoft development community. AJAX is a fundamental technology supported in Silverlight and now, ASP.NET.

7 Responses to Ozzie: Silverlight Supports AJAX...To a Point

© 1998-2024 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.