JScript .NET

JScript .NET was Microsoft’s attempt to turn its browser scripting language into a first-class, compiled .NET language. It was described publicly in 2000, alongside the first unveiling of the .NET Framework, and shipped in February 2002 with the .NET Framework 1.0 and Visual Studio .NET. It kept almost everything a JScript programmer knew: prototype objects, eval, untyped var declarations. On top of that it added classes, interfaces, packages, type annotations and compilation to the Common Language Runtime. The result was one of the earliest production languages to mix dynamic and static typing in a JavaScript dialect. It never caught on. C# and Visual Basic .NET took the .NET world, browsers kept running classic JScript, and the language faded to a compiler, jsc.exe, that still sits unnoticed in the .NET Framework directory of Windows machines.

History & Origins

In 2000 Microsoft was rebuilding its developer platform around the .NET Framework and the CLR. Its two scripting languages, VBScript and JScript, were COM-based interpreters hosted through Active Scripting. They had no real types, no early binding, and could reach only objects exposed through IDispatch. Microsoft rewrote both for .NET. VBScript gave way to the full Visual Basic .NET language. JScript was reworked from the ground up: in Andrew Clinick’s words, “We’ve rewritten JScript to be 100% .NET.”

The language appeared publicly in July 2000, the week of Microsoft’s Professional Developers Conference in Orlando. An MSDN scripting column from that time, discussed on Python mailing lists within days, described JScript’s .NET enhancements: compilation to IL bytecode, optional typing of variables for performance, and type inference. By September 2000 JScript program manager Peter Torr was confirming to outside language implementers that JScript was being targeted at .NET.

The design also ran alongside ECMAScript standardization. Notes from a 22 August 2000 meeting between Netscape’s Waldemar Horwat and Microsoft’s Herman Venter, taken as part of the TC39 work on ECMAScript Edition 4, record that Venter was “readying” a server-side JScript and wanted the language made “easily interoperable with Microsoft’s .NET runtime.” The two disagreed on many points, including strict mode, attribute blocks, and how packages should map onto .NET namespaces. Horwat worried the language was drifting toward Java or C#. Venter, for his part, said new server projects should use C# and saw the new JScript as a language for developers already writing JScript.

The JScript .NET engine first reached the public in the .NET Framework Beta 2 in June 2001, as part of Script for the .NET Framework. The final release came in February 2002 as JScript .NET 2002, which reports itself internally as JScript 7.0. The numbering continues from the classic engine’s 5.x line.

Design Philosophy

Eric Lippert, who worked on the language, later set out the team’s four goals in a 2003 post titled “Designing JScript .NET”:

1. Be an extension of JScript. A legal JScript program should, wherever possible, also be a legal JScript .NET program, and the language should still work as a dynamic scripting language.
2. Support high performance, especially for ASP.NET, and warn about features that hurt it.
3. Integrate well with the CLR and the .NET Framework.
4. Support programming in the large, so that big programs are easier to reason about and to split among a team.

The first and last goals pull against each other, and the language resolves the conflict by making typing optional. You can write JScript .NET exactly as you would write JScript. You can also annotate every variable and get something close to a statically typed .NET language. Or you can mix the two in one file. Lippert’s explanation used addition as the example. When the compiler knows nothing about two operands, a + b needs run-time checks to decide between numeric addition and string concatenation. With both annotated as Number, the compiler can emit a direct numeric add. The compiler also infers types for local variables that are never annotated. It cannot do this for unannotated globals, or where eval might change a variable behind its back.

Key Features

Typed and untyped code side by side

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

import System;

class Greeter {
    private var name : String;

    function Greeter(name : String) {
        this.name = name;
    }

    function Greet() : String {
        return "Hello, " + name + "!";
    }
}

var g : Greeter = new Greeter("World");
Console.WriteLine(g.Greet());

var anything = 42;     // untyped, as in classic JScript
anything = "now a string";
print(anything);

Compiling this with jsc hello.js produces hello.exe, an ordinary .NET assembly.

What JScript .NET added to JScript

Microsoft’s version table lists these elements as new in the “.NET 7.0 and 8.0” column, absent from every classic JScript engine:

Compilation and fast mode

JScript .NET is compiled to CIL before the CLR runs it. The standalone .exe or .dll files it produces still need the .NET Framework. eval and the Function constructor keep working at run time. By default the compiler runs in fast mode, which restricts some older dynamic idioms in exchange for faster code. Programs compiled from the command line can turn fast mode off (/fast-). ASP.NET applications cannot. Microsoft said practically all JScript scripts run unchanged with fast mode off, and some need minor edits to run in fast mode.

Classes and prototypes together

Classic JScript objects are prototype-based, and JScript .NET keeps them. Alongside them it adds class-based objects that any .NET language can use and extend. The expando modifier marks classes or methods that still allow properties to be added at run time. This bridges the two object models.

CLS interoperability and COM

JScript .NET produces Common Language Specification-compliant code. Its namespaces, attributes, by-reference parameters and native arrays work with C# and VB.NET. For backward compatibility, the ActiveXObject constructor still reaches COM components through COM interop.

Limits

JScript .NET was a server-side and application language. Internet Explorer kept the classic JScript engine, so JScript .NET could not script web pages, HTAs or HTCs. It could reportedly use .NET delegates but not declare new ones, which made it awkward to define custom events, for example in Windows Forms code. It also tracked ECMAScript 3. The JSON object and Object.defineProperty, added to classic JScript 5.8 in 2009, never appeared in JScript .NET.

Evolution

Microsoft says JScript .NET 2002, JScript .NET 2003 and JScript 8.0 all shipped with the same language features. After the first release, the language itself barely changed.

Its embedding story ended early. The Visual Studio for Applications (VSA) hosting interfaces, introduced so applications could offer JScript .NET or VB.NET macros, were marked obsolete in the 2005 release. The attribute message reads: “it is being deprecated in Visual Studio 2005; there will be no replacement for this feature.” IDE support went next. A 2012 revision of Microsoft’s Visual Studio 2010 documentation lists JScript .NET as supported only in Visual Studio 2005, and unsupported in Visual Studio 2008, 2010 and 2012.

In 2007 Microsoft announced Managed JScript, a JavaScript implementation for the new Dynamic Language Runtime that shipped in the Silverlight 1.1 alpha and the ASP.NET Futures preview. It was a separate codebase, not a new version of JScript .NET, and it was reportedly dropped from later DLR releases.

Current Relevance

JScript .NET is historical. It was never ported to .NET Core or modern .NET: the Microsoft.JScript API reference lists only .NET Framework versions, from 1.1 through 4.8.1. The assembly and the jsc.exe compiler still ship with the .NET Framework 4.x on Windows, so the compiler is technically present on a very large number of machines. Almost nobody writes new code for it.

In his 2019 notes on the 2003 design post, Eric Lippert wrote that the team had been “doing the right work at the wrong time” and that the effort was eventually defunded. He called TypeScript “everything I dreamed of doing with JScript, just ten years later than I wanted to do it.”

Why It Matters

JScript .NET is an early, shipped answer to a question the JavaScript world spent the next fifteen years arguing about: can a dynamic scripting language take optional type annotations, classes and modules without losing what made it a scripting language? Its answer had typed and untyped code mixed in one file, local type inference, classes coexisting with prototypes, and an expando escape hatch. Similar ideas reached the mainstream years later in TypeScript and ES2015 classes. JScript .NET did not lead directly to either of them. It is better read as evidence that the ideas were workable in 2002, and as a reminder that a language needs a platform that wants it. On .NET, C# already filled that role.