Why didn't the early web support more client side languages?

Flash and Java applets were a big thing, these ARE client side languages. But to work well the vendor had to install a runtime on your PC. Back in the day JavaScript/HTML was too slow and inconsistent for intensive client side work. So people that wanted into intense client side apps used these runtimes.

Cross platform support across many vendors has always been hard. Look at cross platform libraries in C. Different compilers, OS, and std library implementations. Python or Ruby on the other hand have one “vendor” that works to make the runtime consistent on different platforms.

So for something like Python or Ruby to work well, it’d need to either be:

1. A central vendor driving development, who would need to manage and install a runtime on your computer

Or

2. All browser vendors have to buy into a single spec and make a very consistent implementation across their browsers.

Or

3. Compile to JavaScript (or web asm etc)

For (2) browser vendors already invest heavily in JavaScript and have a hard time keeping up! For (1) I’m not sure why any language vendor cares to try to compete with JavaScript seriously. The browser is quite different environment than the CLI or Desktop that it’d be a significant investment without clear upside.

We do see (3) with Typescript and Coffeescript. These create some debugging friction. Also as JavaScript gets marginally better the appeal of these other languages can feel more niche, and many people just use the common denominator.

Sort of a chicken and egg thing. JavaScript initially was only available on Netscape in extremely late 1995. MS implemented their own version as JScript with MSIE 3.2 IIRC in 2Q-3Q 1996. The other extant browsers didn't implement it at all. Through 1996 and 1997 the only real stuff you could do with JS was the intersection between JavaScript and JScript. Given the average speed of the consumer internet was something between 33kbps and 53kbps, we were already pushing the limits of how long people would wait for a page to load before hitting esc and moving on to something else.

To be successful a client side language had to be multiplatform / multibrowser from the start and none of the alternatives were. IBM tried putting Rexx in WebExplorer (I don't even know if that version escaped from IBM internal use). I vaguely recall some sort of extension on whatever shipped on the SGI Indy in 1996 but I don't remember if that was just SGI implementation of JavaScript with Indy enhancements or something entirely different.

Doing anything more sophisticated than simple dhtml menus or form validation was just impractical until broadband became more widespread around 2001-2002. There's a reason web 2.0 happened when it did, it wasn't just the enhancements to JavaScript & the DOM & browsers but the average user started to have access to 1Mbps DSL and cable modems.

An interesting "what might have been" was Grail, a web browser written in Python, with Python as a client-side scripting language. Grail was actually released a month before the first beta of Netscape 2.0 which was the first to have LiveScript (later renamed Javascript) support.

Well, they did. Viola [1] was a very early browser. As well as Grail, mentioned in a sibling, there was at least MMM [2] with OCaml applets. (Those were choices for Emacs browse-url of the right vintage.) There must have been Lisp applets, but I don't remember an implementation; at least Emacs/W3 didn't have them. There was the question of security/trust, of course.

For what it's worth, the very early web looked primitive and rather uninteresting if you already had scripted networked hypermedia (with NeWS), knew of Zanadu, and entirely missed the significance of the protocol and naming system. One learns, at least.

1. http://viola.org 2. https://github.com/aryx/fork-mmm

In the earliest days Java was this thing that showed up in your browser and caused it to just wedge hard (blocking the UI, even) until things got started any time someone decided to embed an applet in a page. Since some people were using it to do all kinds of stupid things (animated fire, anyone?), you could run into it at any point with no warning.

It was ugly. It had terrible looking widgets that were out of place on Windows, Macs, AND Unix boxes - quite a feat at that.

One (dumb) thing JavaScript had going for it was that at least initially, you had to have it on to get CSS action on pages in Netscape. If you turned off JS, then you lost CSS too and things probably looked pretty ugly.

I want to say that some browsers forced you to keep JS on in order to parse a proxy.pac and those of us in corporate/educational environments with filtering proxies had to deal with that, too. Add it to the CSS issue and now you have multiple reasons to leave it on and try working with it. By way of comparison, you could get by with Java disabled.

I still ran with both off in the bad old days and took the lumps, but I'm just cranky that way. I still run with JS off by default.

There just never was a moment where the dominant browser vendors saw a strategic advantage to adding a second language. There was always talk and experiments with other languages, but nothing which got wide support by major browsers.

Netscape/Mozilla always lacked resources compared to the competitors Microsoft and Google which have much deeper pockets. Supporting more languages would be a waste of resources from their perspective. They believed in fixing and improving JavaScript rather than adding another language.

Microsoft did support VBScript as an alternative, and at one point they had such a dominant market share they probably could have pushed VBScript as a viable JavaScript alternative e.g by adding cool features only to VBScript. But MS instead decided to stop developing the browser at that point.

Google invested heavily in their optimizing JavaScript engine to make the web more viable as an application platform. Again this means they didn't have any interest in adding a second language since they would have to make the same investment once more for no benefit.

It is true that JavaScript was not well liked. But the frustration was primarily around incompatibilities in the DOM API and browser-specific bugs. Adding a second language would not solve any of that, it would just double the amount of incompatibilities and bugs.

Supporting any additional language would've required integrating it into the browser engine. Which, in 1995, was pretty much either Netscape Navigator or Internet Explorer (2.0-ish.) Even Mozilla didn't exist before 1998.

So, while I certainly can't make any statement on what was in people's heads at the time — I'm pretty sure trying to integrate a new scripting language into either of those two would've been a daunting task. And both of these vendors would have had some interest in making you not succeed. (MS pushing VBScript [later JScript], and Netscape had some major involvement in JavaScript AFAIR.)

…oh and presumably your additional language wouldn't come included with the browser, and not having to install additional shit was kinda the entire point of JavaScript…

One should distinguish the Javascript language from the DOM API. jQuery make Javascript "less painful" by making the DOM API consistent across browsers and versions. IMO the Javascript language is actually pretty good (given its 10 day gestation). Yes, there are some bad parts but every language has bad parts. Don't use the bad parts. That requires discipline though. And knowledge. Maybe I'm expecting too much.

What still amazes me is that Javascript has had this powerful functional programming capability this whole time and our industry has only recently learned/learning to use it.

"There are only two kinds of programming languages: those people always complain about, and those nobody uses." -- Bjarne Stroustrup

Who was going to make it happen? Microsoft was so dominant, and no one wanted another language that MS owned coming down the pipe, and there wasn't really anyone left to have the resources to push something else, even if they'd wanted to.

These were the days when Microsoft was M$, and it might be hard to remember just how anti open source they were. There was just _no way_ M$ was going to support a new (or existing) open source language in IE unless they were forced.

And none of the niches that loved those languages had any interest in working with M$ to "embrace and extend" their language of choice, so it's not like there was a lot of cooperation out there.

> But the browser-supported languages seems to have been almost entirely Javascript and VBScript.

FWIW I recall only being able to use VBScript in IE (maybe there was a way to run ActiveX components in other browsers?)

I want to say tho, that many (most?) MS Active Scripting languages could run as client scripts, at least I recall Perl ones running in a browser context through ActivePerl.

JavaScript, as I recall, was the answer to Java being crashy and slow on 50 MHz processors. Microsoft tried to make VBscript happen, but was very Microsofty with the licensing, so JavaScript won by default. It’s been good enough to prevent people from successfully replacing it, but annoying enough that people keep trying.

Yes, the browser was a winner-takes-all battle that took all major players to the path of my-technology-is-better-than-any-standard-technology.

In this regard, javascript was itself being pulled from different sides at the same time as well. The surprising thing, in my opinion, is that it managed to get in one piece after all.

I don't think I saw it articulated, but I had the sense that there was a wide belief that the Web needed a new, original language of it's own; that the existing languages would impose too much framework and worldview on totally chaotic evolution. Jskirpt sucked, but it was at least in a position to evolve and become better, which was the main thing that was desired of it right then. Anything else that was invented near its time and purpose invariably had even more suck and less feature.

More languages more problems?

In a desktop environment you can have many languages that compile to the same machine code. You can compile interpreters that run in that machine code.

If browsers had to support ten languages then they would be ten times as complicated. You'd not just have quriks and bugs in Javascript but quirks and bugs in the other languages to worry about.

Today with WebAssembly you could compile any language you want for one runtime, though people have done that with transcoding to Javascript for a long long time.

Tcl

http://www.tcl.tk/software/plugin/

At first Java was considered the ultimate sandboxed client language, though it ended up going in a different direction. Javascript was strictly for silly animations and promotional winky blink until AJAX XMLHttpRequest and Javascript the Good Parts. VBScript was a Microsoft Windows centric sideshow for IE junkies.

The focus of browser development was(and always has been) a kind of Worse-is-Better thing of supplying sexy features to wow users. While client apps are definitely sexy, the overall shape of the browser wars was towards throwing in many bullet-point features of varying utility and complexity - so, not just JS, but JS plus CSS plus additional media types(including plugins). Once you have a client scripting thing with traction, it sucks the air out of the room for a slightly-better client scripting thing. And this could be said of ActiveX, Java, and Flash - they did not keep traction based on what they did better than JS, but what they did that was simply impossible in JS(which mostly amounted to I/O access or certain media types).

The Web introduced the idea of the DOM[1] and Javascript was created to embrace it and extend it making it programable, while Java applets and Flash didn't respect the idea of The Web and didn't embrace the DOM at all, so maybe a false dichotomy was created were either more robust programming languages had to have the full control of the browser skipping The Web (too limiting?) and in the other hand for just operating the DOM Javascript was enough.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Document_Ob...

An interesting fact is that JavaScript really has nothing to do with Java. They paid Sun $5 million to license the word "Java", because it was an extremely popular language at the time.

Related question: how, if at all, did Windows Scripting Host fit into this history? Is there a plausible alternate history where browsers used WSH or some similar technology to execute client-side code in any supported language? Or am I confused about what WSH was/that period of history?

There were attempts back in the day, like Ripterm, and CGI interfaces that worked in almost any language. Things like Compuserve and AOL came in proprietary and then pivoted to internet as we know it. Netscape and WinTCP became common and now we have webkit, gecko and chromium.

I deeply wish they'd just said fuck it and shipped a Python interpreter in an early Firefox version. Yolo, let the chips fall where they may.

Google briefly tried to make client-side Dart a thing, but nobody* ever used Dart at all, for anything.

*statistically...

> Was it the baleful influence of IE6 or some other winner-takes-all effect or what?

This. Then Steve Jobs killed Flash.

https://web.archive.org/web/20100502021750/https://www.apple...

I think one language turned out to be good enough, given what little could actually be done with scripting in the early days. There just wasn't any actual benefit to supporting multiple languages, each of which would need to be a fork with its own DOM API anyway.

Of course, Google tried with Dart, but that never went anywhere.

IE supports ActiveX controls that you can write in literally any language.

> justifiably given its 10 day gestation

God, I hate this meme.

it did support jscript for IE3