Redmond Review

JavaScript's Ascendance Within Microsoft

• By Andrew J. Brust
• 08/31/2012

JavaScript has been part of the Microsoft technology stable since the 1990s, and its prominence in the next wave of Microsoft products is huge. As those new products come to market, it's important to understand and take inventory of Redmond's JavaScript adoption over the years. It turns out that the language's role at Microsoft reveals a lot about the company's tendencies, even as its personnel and products continue to change.

Perhaps most telling about Microsoft JavaScript implementations is that within them, Microsoft tends to couple the language with one that's more proprietary. For example, Microsoft support for JavaScript goes back to the earliest versions of Internet Explorer, but the browser also supported VBScript for client-side scripting, as it does to this day. The two languages have long coexisted on the server side, too. Active Server Pages, or ASP -- the precursor to today's ASP.NET -- supports both VBScript and JavaScript as well.

And this duality extends beyond the Web. Windows Script Host (WSH), for the creation of Windows scripts that took batch file developers to the next level, also supported both languages. The successor to WSH, Windows PowerShell, is programmed with C# and Visual Basic .NET, but it can host WSH scripts, including those written in JavaScript. Over and over, on the client as well as on the server, a Microsoft language and JavaScript have existed side-by-side.

The Tradition Continues
The language partnership has continued in the Microsoft .NET Framework era. While few people wrote them, the first three versions of Visual Studio .NET supported the creation of .NET applications using JScript .NET as the programming language. And, of course, the JavaScript editing and debugging experience in Visual Studio has built up nicely over the years.

As Microsoft gets ready to rev nearly every product in its stack, the role of JavaScript is only increasing. Windows 8 applications, of course, can be developed in JavaScript and HTML5; the framework for the forthcoming LightSwitch HTML5 client apps uses JavaScript as its extensibility mechanism; apps (formerly code-named "Agaves") for Office and SharePoint 2013 are written in JavaScript and use HTML as well. The companion language strategy continues, too. Windows 8 apps can be written in Visual Basic .NET and C# with XAML. LightSwitch desktop clients can be as well, and the two .NET languages are still used for COM-based add-ins in Office as well as for conventional SharePoint development.

Microsoft has even developed a framework whereby Hadoop MapReduce big data jobs can be written in JavaScript. Visual Basic and C# are not part of this framework; I guess there's always an exception to the rule. But this one makes sense, given the Java and Linux pedigree of Hadoop. After all, Microsoft wants to contribute things that will resonate with the Apache Hadoop community, and JavaScript fits the bill.

Function oliveBranch()
And that raises an interesting point: Microsoft uses JavaScript when it wants to appeal to developers beyond its own ecosystem. I'm not sure if that's been a premeditated strategy, or merely a pattern the company has followed, but I don't think that matters. Whether intentionally or habitually, Microsoft uses JavaScript to win hearts and minds from outside the fold, and uses its own languages to provide an even stronger platform for its more committed developer base.

The two-pronged strategy doesn't always result in home runs. Few Microsoft developers used VBScript in the browser, or JavaScript on the server (but the popularity of Node.js proves the idea is far from crazy). We'll see whether Windows 8 applications are predominantly developed with .NET languages and XAML, or JavaScript and HTML. And, heck, maybe Agaves will turn out to be the next smart tags.

But whether each JavaScript initiative succeeds, the reliable consistency of a JavaScript option has great value. It shows that Microsoft keeps itself in recruiting mode, and yet continues to take care of its own. A year ago, many developers feared JavaScript would be the only option for developing Windows 8 apps. I had a hunch that wouldn't be the case, and the Microsoft BUILD conference proved my hunch correct.

With some analysis I now see where my hunch came from: For nearly 20 years, Microsoft has used JavaScript as its emissary, but Redmond has always served the home front as well. Whether by design or by accident, that strategy has worked. Hopefully it will continue to do so, because Redmond shows no sign of changing course.

(Ed. Note: this column has been updated to correct an error. Visual Studio 2010 does not support JScript.)