Go-based AxonASP engine beats Microsoft's native cscript in Classic ASP benchmarks

A Go engine that untethers Classic ASP from Windows

VBScript and Classic ASP have spent their existence welded to Microsoft's own execution stack: interactive scripts run through cscript.exe, and web pages through the IIS worker process. According to a benchmark article published on dev.to, a project called AxonASP replaces that dependency with an execution engine written in Go, shipped as a standalone binary that runs on Linux, macOS, BSD and Windows — with no Windows licence involved.

How the benchmark was run

The article describes a test built by developer Jeffrey Heping, who translated all 23 Gang of Four design patterns into VBScript, complete with classes, recursion, collections and callbacks. The identical 23 files were then run in five environments on Windows 11, with each iteration timing the whole lifecycle: starting the process, compiling the code and executing it.

The reported averages:

• AxonASP in classic syntax mode (axonasp-cli): 0.092 seconds
• AxonASP in modern syntax mode (axonasp-cli): 0.102 seconds
• cscript.exe, Microsoft's native VBScript host: 0.107 seconds
• VB.NET on the dotnet runtime: 0.233 seconds
• ASPPY, a Python-implemented engine: 0.247 seconds

Every environment passed all 23 pattern tests. AxonASP's classic-syntax mode came in roughly 14 percent faster than cscript.exe, though on this test the gap between the two is a matter of milliseconds. The write-up notes that ASPPY behaves correctly but pays normal Python interpreter costs in speed, memory and processor use — the trade-off expected when an interpreted Python layer drives script execution rather than a compiled Go binary.

Where the advantage reportedly widens

The 0.092-second figure is a cold start on the command line: it includes spinning up the process and compiling the script. In its web configurations (axonasp-http and axonasp-fastcgi), the engine parses and compiles VBScript or JScript into an internal bytecode representation held in memory, so later HTTP requests skip the parsing stage entirely and run the cached bytecode directly. The dev.to article argues this design gives AxonASP a structural edge over IIS's traditional ISAPI execution for sustained traffic — although no web request throughput figures are published alongside the CLI benchmark.

An engine, not just a web server

AxonASP positions itself as a general execution engine rather than strictly a web server. The axonasp-cli binary lets VBScript and JScript run directly from the terminal on all supported platforms, effectively turning VBScript into a cross-platform automation language that no longer needs an HTTP host or a Windows machine.

Because the engine is written as modular Go code, developers can import the AxonASP runtime into their own compiled Go applications and gain native VBScript and JScript execution inside third-party binaries. The article reports that Jeffrey Heping used this modularity to build engines that run Microsoft HTA (HTML Application) files natively across operating systems, decoupling those artifacts from Windows entirely.

What to weigh before betting on it

These figures come from a single dev.to post documenting the project's own benchmark, not an independent audit. Hardware specifications, iteration counts and the methodology behind the averages are not detailed beyond the per-run lifecycle timing, and the claim about web workloads rests on the caching architecture rather than published request-level measurements.

Why it matters

Plenty of organisations still maintain Classic ASP and VBScript estates, and the usual options — rewriting in a modern stack or paying for Windows hosting indefinitely — are both costly. A cross-platform engine that executes the same code faster, runs in any container or deployment pipeline, and can be embedded inside Go binaries offers a third path: move the workloads off Windows without rewriting them. If the results hold up under outside testing, AxonASP turns legacy VBScript into something that can be re-deployed, automated and embedded rather than merely preserved.