JScript

JScript is Microsoft’s dialect of JavaScript - born in August 1996 inside Internet Explorer 3.0 as a reverse-engineered answer to Netscape’s hit scripting language, and destined to outlive the browser that carried it. For a decade it was, by installed base, one of the most widely deployed programming language implementations on Earth: every copy of Windows from Windows 98 onward shipped it, every Internet Explorer ran it, and every Classic ASP server executed it. JScript is also a language of consequence beyond Microsoft’s walls - it was one of the two implementations reconciled into the ECMAScript standard, and the XMLHTTP object first scripted from JScript pages became the seed of Ajax and the modern web application. Today the language is dormant: frozen at its 2009 feature level, retired from the browser, yet still present in Windows 11, where a hardened descendant of its engine quietly runs the scripts that never went away.

History and origins

Netscape’s JavaScript - announced in December 1995 and shipped in Navigator 2.0 in March 1996 - made the web programmable, and Microsoft - then executing its famous pivot toward the Internet - needed a compatible answer for Internet Explorer. Netscape was not about to license its language to its chief rival, so Microsoft’s engineers did what the era demanded: they reverse-engineered it. The result, named JScript to sidestep Sun Microsystems’ “Java” trademark (which Netscape had licensed for the name “JavaScript”), shipped as JScript 1.0 with Internet Explorer 3.0 in August 1996 - the same month Netscape Navigator 3.0 arrived with JavaScript 1.1.

JScript did not arrive alone. It was one of the founding components of Microsoft’s Active Scripting architecture (part of the ActiveX push of 1996): rather than being welded into the browser, the JScript engine was a pluggable COM component that any application could host. This single design decision defined JScript’s career. Within months it was running server-side in Active Server Pages on IIS (JScript 2.0, January 1997), and by 1998 the Windows Script Host in Windows 98 let administrators execute .js files directly on the operating system. The same language ran in the browser, on the web server, and at the Windows command line.

The two-dialect situation - JavaScript and JScript, similar but diverging - was exactly the fragmentation the young web could not afford, and in November 1996 standardization work began at ECMA with both Netscape and Microsoft participating. The resulting ECMA-262 (ECMAScript) standard, published in June 1997, was deliberately written to reconcile the two implementations. JScript 3.0, shipped with Internet Explorer 4.0 in October 1997, was among the first implementations aligned with the new standard, and from then on Microsoft positioned JScript explicitly as its ECMAScript implementation.

Design philosophy

JScript’s design brief was unusual: be JavaScript, but be Microsoft’s JavaScript. That meant near-complete compatibility with the ECMAScript core - the same prototype-based objects, dynamic weak typing, first-class functions, and C-family syntax - extended in directions that served the Windows platform:

• Active Scripting host neutrality. JScript itself has no I/O, no DOM, no file system. Everything comes from the host: Internet Explorer supplies document and window; ASP supplies Request and Response; Windows Script Host supplies WScript. The language is a pure engine that any COM application can embed - the same architecture that made VBScript its constant sibling.
• COM and ActiveX automation. new ActiveXObject("Scripting.FileSystemObject") gave JScript scripts the run of the entire Windows automation surface - Office, WMI, ADO databases, the shell. This made a “browser language” into a systems administration tool.
• Conditional compilation. JScript’s best-known proprietary feature hid engine-specific code inside comment blocks (/*@cc_on ... @*/) that other browsers would ignore - an extension to the ECMAScript standard found in no other implementation, and a period artifact of writing one page for two incompatible browsers.
• Pragmatic period extensions. JScript exposed Microsoft-specific objects such as Enumerator (for iterating COM collections) and VBArray (for interchange with VBScript’s arrays), stitching the language into the fabric of late-1990s Windows.

Versions and evolution

The classic engine’s history tracks Internet Explorer’s almost exactly:

Two successors branched off. JScript .NET (2002, with the .NET Framework and Visual Studio .NET) reimagined the language as a compiled, optionally-typed citizen of the Common Language Runtime - technically interesting, but stricter semantics cost it the loose dynamism that made JScript useful, and it never found an audience. Chakra (internally “JScript 9”), the from-scratch engine in Internet Explorer 9 (March 2011), brought just-in-time compilation and ECMA-262 5th edition support, and carried Microsoft’s browsers through Internet Explorer 11 and the original Edge.

Classic jscript.dll, meanwhile, simply never left. Frozen at the 5.8 feature level, it kept shipping in every Windows release for Windows Script Host, HTAs, Classic ASP, and innumerable enterprise scripts - a 1996-era interpreter still present on over a billion machines well into the 2020s.

The security afterlife

Longevity had a price. A dynamic interpreter from 1996, reachable from scripts and legacy web content, became one of Windows’ most-attacked legacy components: JScript engine vulnerabilities were repeatedly exploited in the wild, and Microsoft eventually provided ways for enterprises to disable JScript execution in Internet Explorer zones outright. The endgame came in two moves: Internet Explorer 11 was retired on June 15, 2022, and in July 2025 Microsoft announced that beginning with Windows 11 version 24H2, all JScript scripting is handled by default by JScript9Legacy - an Active Scripting engine derived from the Chakra lineage - in place of the original jscript.dll. Existing scripts keep working; the twenty-nine-year-old interpreter finally stepped out of the default path.

Current relevance

JScript is dormant, not dead - and the distinction matters more than for most languages in this encyclopedia, because dormant JScript still runs in production. Classic ASP applications remain supported on modern IIS. Enterprise logon and deployment scripts written for Windows Script Host continue to execute on Windows 11, now atop JScript9Legacy. Anyone with a Windows machine can still open a terminal and run a .js file with cscript.exe, exactly as an administrator would have in 1998:

1
2
3
4
5

// hello.js — run with: cscript //nologo hello.js
WScript.Echo("Hello, World!");

var shell = new ActiveXObject("WScript.Shell");
WScript.Echo("Windows directory: " + shell.ExpandEnvironmentStrings("%WINDIR%"));

No new development happens in the language: Microsoft’s guidance for automation long ago moved to PowerShell, and for web work to standard modern JavaScript. But as living industrial archaeology - a 1990s language still doing its original job on current operating systems - JScript has few rivals.

Why it matters

It co-authored the web’s language standard. ECMA-262 exists in the form it does because there were two JavaScripts in 1996 that had to be reconciled. JScript gave Microsoft its seat at that table, and the standard that resulted - ECMAScript - became the constitution of the world’s most widely deployed programming language.

It accidentally seeded Ajax. The XMLHTTP ActiveX object, scripted from JScript in Internet Explorer, introduced the pattern of fetching data from a server without reloading the page. Standardized elsewhere as XMLHttpRequest, that one JScript-accessible object made Gmail, Google Maps, and the entire single-page-application era possible.

It proved the embeddable-engine model. Active Scripting’s pluggable-engine design - one language runtime, many hosts, from browser to server to shell - prefigured the architecture that Node.js would make famous a decade later with V8: the browser’s language, everywhere.

It is a case study in software longevity. JScript demonstrates both halves of the legacy bargain: code written against it in 1998 still runs in 2026, and the engine that guaranteed that compatibility became such a liability that Microsoft ultimately swapped it out from under the scripts rather than turn them off. Few languages illustrate so cleanly what “backward compatibility” actually costs, and what it buys.