Ask HN: Why didn't the early web support more client side languages? | Hacker News Reader

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

38 pointsdcminter69 comments

Disclaimer: I'm a backender so I may have this all wrong :)

The script element in HTML has provided the language property since its introduction, though nowadays it is deprecated in favour of the type attribute.

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

Given that Javascript is considered to be an at best quirky [0] language (justifiably given its 10 day gestation) how come the browser ecosystem never expanded to accommodate more direct scripting languages - particularly in the early days when Javascript libraries were rare beasts? As I remember it Javascript was deeply unpopular with devs until libraries like JQuery came along to make things a little less painful.

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

[0] https://www.goodreads.com/book/show/2998152-javascript

View on HN

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

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

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.

> 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.

I have no idea with Coffeescript (I've read about it, but never used it). But my current job is basically spent all day writing TypeScript.

1) There is no debugging friction. I can debug TypeScript directly in my browser.

2) It isn't marginally better over JavaScript. It is leaps and bounds better than JavaScript.

TypeScript compiler will catch many, many, many common problems straight away (provided it is configured correctly). I have written a lot of JavaScript and I don't enjoy going back to having to write regular JavaScript.

The friction with typescript is the build environment (speaking as someone who also prefers it, and uses it all day).

If someone else is handling that work for you (and in most companies this does essentially become a core responsibility for a few critical maintainers) then yes - Typescript feels great.

If you have a small, single person project - there's enough real overhead there that I'm not sure typescript is the right initial choice.

> The friction with typescript is the build environment (speaking as someone who also prefers it, and uses it all day).

You can literally do:

    tsc filename.ts

And you will have a javascript file that you can run in a browser. No configuration files needed, just need to install the typescript compiler. Sure if you need more complicated things. You will need a more complicated setup. But it is no worse (and in someways better) than most of the ecosystem.

> If someone else is handling that work for you (and in most companies this does essentially become a core responsibility for a few critical maintainers) then yes - Typescript feels great.

I don't know where you work. However I've done this myself by myself. It is well documented and it isn't that difficult. I think the hardest to setup from scratch is webpack, but Gulp is fairly straightforward.

I've have set stuff up completely from scratch and created my own framework with TypeScript (I was bored during lockdown) and it takes maybe a day to figure out with webpack.

Not something for a beginner. However you don't need a whole team to do this or specific people looking after it.

> If you have a small, single person project - there's enough real overhead there that I'm not sure typescript is the right initial choice.

The same could be said of any other language where you need any sort of build system and a compiler.

> We do see (3) with Typescript and Coffeescript

And ClojureScript, and PureScript, and Elm, etc

Honestly, in my hobbyist experience, JavaScript is a joy to use as a compilation target. All the flexibility and the laundry list of features which can make it a handful to use directly, make it a wonderful base for nearly any kind of language you can imagine. And because it's higher-level, you can focus your energy on your own language instead of on re-implementing the fundamentals from scratch. And then of course it performs better than most similarly-flexible languages, and runs anywhere.

WebAssembly is a much better target for compiled languages. And JS runs anywhere in the same way that Java does, which is wherever someone has installed a virtual machine for it, which is usually a web browser or Node for JS. But it doesn't run on more places than C or C++, which can be compiled to run on almost any hardware in existence.

> WebAssembly is a much better target for compiled languages

Depends on what you're trying to do. My language projects are almost always higher-level and garbage-collected, so again, targeting WASM would mean re-implementing fundamentals from scratch all the time. I'm glad to focus instead on interesting language features, translating those to be in terms of JS features.

All fair points, but still, don't you think it's a little surprising that browsers never supported perl client side? That seems like the obvious one to me given all the cgi scripting written in it.

> surprising that browsers never supported perl client side?

They did, actually:

https://perlhelp.web.cern.ch/Components/Windows/PerlScript.h...

If you installed ActivePerl, you could use, in IE 5.0,

  <script language=perlscript>…</script>

I even remember using this for shits and giggles. And then I noticed noone else was willing to install it, and gave up on it.

(Don't get confused by the server-side bits, those are for IIS, this stuff did both server-side and client-side...)

[Ed.add.: also I don't think Netscape ever supported anything other than JavaScript, but I'm not sure of that.]

I actually used the server-side version of PerlScript to mix some code from CPAN into a classic ASP application, way back at the dawn of my career. It was pretty neat.

I, too, had dreams of using the client-side version, but getting folks to install it was indeed much too tough of a sell.

Nice! I had no idea that existed!

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.

That's crazy.

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

I was going to mention Viola, which is a truly impressive application. Diving into the Viola docs, notably the paper and book, is strongly recommended.

http://viola.org/viola/violaIntro.html

http://viola.org/viola/book/preface.html

There's also BrowseX, a Tcl/Tk based web browser which supported, you guessed it, Tcl-based web scripts. It was notably included on the Linux Bootable Business Card (LNX-BBC) micro-distribution, see a Linux Journal review here:

https://www.linuxjournal.com/article/6890

There's still a Sourceforge project page:

https://sourceforge.net/projects/brx/

LNX-BBC:

https://archiveos.org/lnx-bbc/

https://web.archive.org/web/20050204083600/http://www.lnx-bb...

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.

> If you turned off JS, then you lost CSS too

Bizarrely, this was because CSS was implemented on top of JavaScript in Netscape. Netscape was initially not a fan of CSS and developed their own JavaScript-based style sheets. Then at some point they decided to support CSS anyway, and implemented it by transforming the CSS to JavaScript style sheets. This architecture was allegedly the reason for the incredibly buggy support for CSS in Netscape.

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…

To be fair, Mozilla is more or less what became of Netscape.

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

Also worth noting that an alternative language at the time probably would have been Perl or VBScript. Not sure this would have been such an improvement over JavaScript, whatever it's faults!

A scheme-line language would have been cool though, and great as a compilation target.

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.

You forget that at the height of the browser wars Netscape was vying with Microsoft to add new features and they didn't particularly need to be compatible; remember Javascript wasn't (initially) available on Internet Explorer, it was Netscape only for at least a year or two. I wonder that Netscape didn't add a few more languages to the party as a fire and motion exercise against the competition.

The moment "does it run on IE?" became uppermost in developers minds was (as I see it) the moment the original browser wars ended and the long cold war began. But there was a cambrian explosion of often-incompatible features before that.

Edit: I definitely buy that as the reason that IE didn't adopt any other languages, though, and maybe there just wasn't time for Netscape to bolt another one on? Or maybe their great rewrite got in the way (I'm hazy about the timeline for that).

Hm, yeah I wonder if there was really time/resources for Netscape to pull that off if they'd even wanted. There was so much going on with HTML/CSS/etc. simultaneously.

And it definitely wasn't certain at the time that a scripting language, running in the browser, was going to be The Future.

> I wonder that Netscape didn't add a few more languages to the party as a fire and motion exercise against the competition.

Not a great strategy when your competitor have much more resources than you have yourself. Microsoft could quickly reverse-engineer any Netscape feature, and Netscape had limited resources. Any wasteful drain on Netscapes resources would just have played into Microsofts hands.

> 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.

My (hazy) memory says early IE only did VBScript, trying to "win out" against JavaScript, then MS "invented" JScript, until at some point they gave up and added JavaScript.

And yeah I used PerlScript (ActivePerl) in some hacks, but you had to install that separately which pretty much killed it.

JScript was the same as JavaScript. MS just called their implementation JScript for trademark reasons.

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.

> JavaScript, as I recall, was the answer to Java being crashy and slow on 50 MHz processors.

[citation needed]

Having lived through that period of time, I do not recall Java applets and JavaScript ever being considered to be in the same category / trying to solve similar problems.

Java literally runs on smart cards, including SIM cards: https://en.wikipedia.org/wiki/Java_Card — and did so since the 90s.

My guess is, applets were crashy for different reasons than CPU speed.

JavaScript was contemporaneously developed alongside Java, to target a different niche:

https://auth0.com/blog/a-brief-history-of-javascript/

Java wasn't crashy as I recall it. Nor was it slow once the applet started. It was slow in the sense that downloading the class files (usually over a modem, sob) and firing up the JVM wedged your webpage for a good while!

Historical records seem to contradict themselves on this matter. What I recall reading was that they were created for two different things: JavaScript was created to add basic interactivity on the page, and Java was intended to be used for more CPU-intensive work.

> JavaScript, as I recall, was the answer to Java being crashy and slow on 50 MHz processors.

Not in the least - The early scripting language Mocha, was first renamed to LiveScript then Netscape and Sun did a license agreement and it became JavaScript. And the idea was to make it a complementary scripting language to go with Java, with the compiled language.

Purely marketing, to attempt to use the popularity of stand-alone Java for an in-browser scripting solution.

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.

Maybe? But there was enough demand for other languages/capabilities that the Java and Flash plugins existed.

At the peak of the browser wars I'd have expected this to be something tried to get mindshare (or maybe it was and didn't work well enough that I ever heard about it?)

Edit: E.g. HTML 4 spec (at least) offers text/tcl as a plausible language value. Did anyone ever offer that? Surely someone must have supported text/lisp as well at least briefly :)

According to stories I heard from people who were in the room, the W3C was on the verge of adopting Tcl as the preferred browser scripting language, when Java suddenly and unexpectedly got popular and Netscape decided they could use it as a network system language to challenge Microsoft. JavaScript came shortly afterwards, developed and named purely for marketing reasons to bolster Java uptake.

Then came Microsoft's ever-so-slightly incompatible Jscript, and the next ten years of web history was a fight to see who could lock the most web developers in the trunk.

No room for alternative languages in that scenario.

If anything would support text/lisp, it would be the browser built into emacs that my coworker keeps pointing out VIM doesn't have.

I congratulate you; if you cannot have an ally then a worthy foe is almost as good ;)

Tcl

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

Tcl is so useful, I wish it would have taken off more than it did. I do a little 'chef kiss' every time I talk about how useful Tcl/Tk is/was in its day...

Then we settled for PHP somehow :/

Followed by the drupal era.

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.

Don't forget client side form validation as the main pre-AJAX "serious" usage. Often in the sense of "seriously misguided" when there was no corresponding server side validation of course!

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.

And don't I as a Java developer hate the people who made that decision . TO THIS DAY it confuses people (often in HR) that they're not the same language.

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?

Microsoft supported a model with pluggable scriping engines which was supported both on Internet Explorer (for client side scripts) and WSH for system-level scripting. The same technology also allowed you to use multiple scripting languages with the classic ASP web framework.

> Microsoft supported a model with pluggable scripting engines which was supported both on Internet Explorer (for client side scripts)

So what happened? Given that we lived through an era of Internet Explorer dominance, and Windows/IE was apparently shipping with a variety of scripting languages built in, how did that not lead to options for client-side scripts? (This all took place before my career change into programming, so I didn't really notice as I was living through it – sorry if that results in some ignorant questions).

IE only shipped with JavaScript and VBScript built-in. Other language engines could be installed (Perl and Python for example), but realistically nobody would write client-side code in a language which required a visitor to install support for it.

VBScript was the only viable contender, but it never really had any compelling advantages compared to JavaScript. JavaScript is often criticized for quirky design and syntax, but if anything VBScript was worse.

Also the pluggable script engines were based on COM, so only worked on Windows. I don't think VBScript was ever supported in IE for Mac.

I don't think Microsoft ever saw a strategic advantage to promoting alternative languages on the web. Otherwise they would have done a lot more.

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...

Nobody would had used it though as long as it was only supported in Firefox.

Glad they didn't though!

> 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.

Not anymore, it doesn't ;)

https://en.wikipedia.org/wiki/ActiveX

> Microsoft dropped ActiveX support from the Windows Store edition of Internet Explorer 10 in Windows 8. In 2015, Microsoft released Microsoft Edge, the replacement for Internet Explorer with no support for ActiveX, this event marked the end of ActiveX technology in Microsoft's web browser development.

> justifiably given its 10 day gestation

God, I hate this meme.

Why? It seems to be reasonably well cited; is it wrong?

It's not wrong, but it's also misleading and cited as part of the larger "hurrdurr JavaScript bad" meme.

It was originally intended as a simple scripting language to add interactivity to browsers, so the initial implementation was quick and dirty, but the language has evolved a lot since then. The "10 day gestation" has nothing to do with the quality of the language.

He calls the language "quirky at best". Lots of people find it expressive and powerful, and those quirks are easy to ignore. For example, == is terrible, but we have === now. In 5 years of professional JS development, I've never seen anybody use the former.

(I'm the OP)

I guess some of my dislike of Javascript leaked in. But for the most part this is about the early days of the language when its quirks were more glaring as the mitigations and improvements hadn't been discovered/created.

My personal feelings about it are more a general distaste for dynamically typed stuff. I rarely had to tangle with it professionally and cheerfully admit my ignorance of best practices!

it did support jscript for IE3

Reply on news.ycombinator.com