Every now and then I’m reminded of a technology from the early days of the web and wonder if I imagined it.

This week, it was Mohammad using WebAssembly to run Perl in his browser. Which led to me thinking about PerlScript.

If you’re a certain age, and you spent any time developing web applications on Windows in the late 1990s, you’ll probably remember it. If you’re younger than that, you’re quite likely to think I’m making it up.

Because, for a brief period, Internet Explorer could run Perl inside <script> tags.

Not JavaScript.

Perl.

It sounds absurd now.

It wasn’t absurd then.

The browser wars were weird

It’s difficult to explain to younger developers just how chaotic the web was in the late 1990s.

Today, if you’re building a web application, you write HTML, CSS and JavaScript. Every browser understands them. If you invent your own alternatives, you’re going to have a very lonely website.

None of that had been settled in 1998.

Microsoft and Netscape were engaged in what became known as the Browser Wars. Every release was packed with new features that only worked in one browser. Sometimes the other side copied them. Sometimes they ignored them. Either way, developers were left trying to support both.

We got Java applets. ActiveX controls. VBScript. Browser-specific CSS. Browser-specific DOM APIs. <marquee>. <blink>. Layers. Filters. Behaviours.

And, almost forgotten today, the ability to write client-side Perl.

Seen in that context, PerlScript wasn’t especially strange.

It was just another way for Microsoft to say, “Look how much more capable Internet Explorer is.”

Active Scripting

The clever part was that Internet Explorer wasn’t actually designed to execute JavaScript.

It was designed to host scripting engines.

JavaScript (or, more accurately, Microsoft’s implementation called JScript) was simply one of the engines that happened to ship with the browser. VBScript was another.

If you installed additional scripting engines, Internet Explorer would happily use those too.

One of those engines came from ActiveState.

It was called PerlScript.

That meant you could write something like this:

Load the page in Internet Explorer on a machine with ActivePerl installed and it would execute exactly as you’d expect.

The browser itself didn’t understand Perl.

It simply handed the script to the installed PerlScript engine.

Looking back, it’s actually a pretty elegant architecture.

ActiveState’s role

Around this time, ActiveState was doing fantastic work making Perl a first-class citizen on Windows.

For years, Windows had been an awkward platform for Perl developers. ActivePerl largely solved that, becoming the standard distribution for Windows users.

PerlScript was one part of a much bigger picture.

The same scripting engine worked not only inside Internet Explorer, but also with Microsoft’s Active Server Pages (ASP) and Windows Script Host.

Write the engine once and Windows would happily host it wherever scripting was supported.

It was a neat example of software reuse.

Why it never caught on

Of course, there was one rather obvious problem.

For your web page to work, your visitors had to:

• be using Internet Explorer;
• be running Windows; and
• have PerlScript installed.

That isn’t exactly the recipe for a successful public web application.

For internal corporate systems it made a certain amount of sense. On the open web, JavaScript was always going to win.

An alternative web

What I find fascinating is that Microsoft’s approach wasn’t obviously wrong.

Imagine an alternative history where browsers had standardised on the idea of pluggable scripting engines.

Instead of asking whether a browser supported JavaScript, we’d ask whether it had PythonScript, PerlScript or RubyScript installed.

The browser itself would simply dispatch each <script> block to the appropriate interpreter.

In another timeline, perhaps that’s exactly what happened.

Instead, the web converged on a much simpler idea.

Every browser should speak the same language.

That language happened to be JavaScript.

Sanity eventually prevailed

Ironically, the browser wars eventually destroyed themselves.

By 2001 Internet Explorer had effectively won. IE6 reached an extraordinary market share, Netscape faded away and Microsoft slowed browser development to a crawl.

That turned out to be good for nobody.

Firefox arrived in 2004 and reminded Microsoft that browsers were still worth competing over. Chrome followed in 2008 and accelerated the change.

But something important had shifted.

The competition was no longer about inventing proprietary technologies that locked developers into one browser.

Instead, browsers competed on standards compliance, JavaScript performance and developer tools.

There were still plenty of innovations, but they increasingly became standards rather than vendor-specific features.

Frankly, that was a much healthier place for the web to end up.

Forgotten technology

One thing that surprised me while looking into PerlScript again was how little remains on the web.

There are countless articles about Flash, Java applets and Silverlight.

PerlScript barely gets a mention.

Perhaps that’s because hardly anyone used it. Or perhaps it was simply overshadowed by ActiveState’s much more successful server-side work.

Either way, it feels like an important little footnote in the history of the web.

A reminder that the future wasn’t always as inevitable as it now appears.

So no, I hadn’t imagined it.

There really was a time when you could install Perl on a Windows PC, open Internet Explorer and use it to execute Perl in a web page.

Looking back nearly thirty years later, it feels less like a forgotten product and more like a glimpse into an alternative history of the web.