Why is there just support for JavaScript and some VBScript in browsers today? I know JavaScript is good and all, but wouldn't having the option of using another programming language help promote different development styles?

  • 1
    See this question on Stack Overflow: stackoverflow.com/questions/2872037/…
    – Corey
    Commented Feb 10, 2011 at 17:10
  • 1
    Your question is precisely why Google made GWT.
    – jhocking
    Commented Jun 21, 2011 at 22:30
  • 1
    I believe the whole point of the DOM API was to provide support for multiple languages. Thing of it is, JS is actually really well-suited to the challenge. It normalizes like nobody's business and first-class functions are huge in a heavily event-driven paradigm. What it really came down to is that nobody wanted to let MS make that decision and nobody came up with a better one than JS. Also, Java Applets were really, REALLY lame. Commented Oct 31, 2013 at 0:30
  • It is possible that the new py-script, is going to change the game. But, I think it will work in co-operative way with JS rather than replacing it. I don't think it is not even its purpose to work like JS.
    – LoukasPap
    Commented May 17, 2022 at 16:46
  • You don’t want to promote different programming styles.
    – gnasher729
    Commented Sep 19, 2022 at 8:02

10 Answers 10


There is no need to add support for multiple languages, a solution would be to standardize on a generic bytecode that could be used by language implementors. But there are currently no plans for this (it's been suggested).*

Languages can be implemented on top of Javascript too. Javascript is good enough to allow other languages to be implemented on top of it. And there are many examples of this already.

(*) Update from 2022: today we have a standard for this (WebAssembly) which is supported by all major browser engines.

  • 3
    +1 - For pointing out that JavaScript is a powerful language that can be used as an abstraction for other languages. It would be an interesting project to write a Firefox extension that would run client side C++ or Java! <script type="text/cpp" src="test.cpp"></script>.
    – jmort253
    Commented Feb 7, 2011 at 6:26
  • 2
    @jmort253, take a look at native client. Commented Feb 7, 2011 at 8:16
  • Native client is definitively interesting but unless Mozilla adopts it too, there will not be any traction. Last I checked they weren't yet ready to take it on.
    – nkassis
    Commented Feb 7, 2011 at 20:10
  • 1
    I found Gestalt ~ a couple years ago: gestalt.codeplex.com it is a good example of building other scripting languages on top of Javascript. Commented Feb 8, 2011 at 0:31
  • 2
    Another example: Google Web Toolkit? Java is compiled to JavaScript
    – MarkJ
    Commented Nov 7, 2011 at 12:00

JavaScript is the de-facto standard and has been since 1996. Being a standard simply because there is no competition isn't exactly fair, but I haven't heard a lot of complaining about why there isn't another language included.

Adding another "standard" language promotes all sorts of fun little issues.

  • How will they work with other languages?
  • Will the DOM be shared?
  • Could scripts written in both still work?
  • Porting libraries to both
  • 8
    Actually I think JavaScript is the language used in Mozilla's Gecko. In IE we have JScript. Most other browsers use something that more or less follows ECMAScript specifications. These all languages are for simplicity's sake called 'JavaScript', while in fact they do differ.
    – Mchl
    Commented Feb 10, 2011 at 11:20
  • 1
    You can have multiple languages that generate same bytecode. Look at JVM – Groovy, Java, Scala, Clojure, jRuby can be directly compiled to JVM bytecode. This way, they will share same DOM api, and can be made interoperable. Though it's exponentially harder to implement with JavaScript VM since it's interpreted. Commented Oct 8, 2013 at 12:42

Think of the inconsistencies between browsers for their support of javascript alone. Now think about how it would be if there were more languages.

  • 5
    Yay, it's already there, client side VBScript ... uugh, shudder.
    – ocodo
    Commented Feb 7, 2011 at 4:01
  • 1
    +1 I think our heads would explode if we had a subset of other languages to memorize for each of the main browsers and their versions. Good answer.
    – jmort253
    Commented Feb 7, 2011 at 6:28
  • 4
    This might be nitpicking, but... browsers' support of JavaScript [ECMAScript] has actually been very consistent across the board since the beginning. What has been inconsistent is their implementation of the DOM (and associated methods). From a practical (and historical) standpoint, it's hard to separate the two--since the only real use of JS has been to manipulate the DOM in a browser--but with the rise of server-side JS (things like NodeJS), this actually does become a somewhat important distinction.
    – josh3736
    Commented Feb 7, 2011 at 14:40
  • was going to write pretty much exactly this as an answer, the internet has enough standards that aren't followed or supported. the fact that the jumbled mess we have works half as well as it does is nothing short of a miracle.
    – Ryathal
    Commented Dec 6, 2011 at 21:56
  • 1
    Josh is right. It's where you plug into the individual browser's borked-idea of how things are supposed to render and be accessed by JS that stuff got ugly but IE is finally at least attending to long-standing proprietary API issues on that front (even though it continues to lag behind the latest in just about everything due to MS's fateful decision to link their browser to their file navigator - jackasses). Commented Oct 31, 2013 at 0:26

Browsers have to be standardised, so that what you develop works everywhere, on all browsers.

If you have multiple languages kicking about, then you have to ensure that they all perform very similarly. If you are a web developer and you have a choice of languages, which may or may not be supported in some locations, then that is an additional headache.

Javascript is a very flexible language, it is imperative, it is functional, it can be OOP (after a fashion with prototypes), and it is interpreted. Now with decent engines like in Chrome, it is reasonably capable of doing some good stuff. Extra languages would just set things back here, look at VBScript, IE only, and so anything that is written in it is bound to a particular browser and platform, nightmare.

  • 2
    The important point here being "with decent engines like in Chrome". Doing anything even mildly taxing causes even IE8 to start limping like it's got a broken leg, while recent versions of Firefox, and Chrome since forever that I've used it (this was the reason I switched infact) skip along without missing a beat. Commented Feb 7, 2011 at 7:27
  • 1
    @Matthew Scharley: IE is generally sluggish, indeed it seems to get worse with every version. They need to up their game, or they will be out of it. The only reason IE has any hold is because of OS inclusion, now they have to put a selector up on first use, that has dropped a lot.
    – Orbling
    Commented Feb 7, 2011 at 8:22
  • "it can be OOP"... It is OOP! Inheritance is not what defines OOP. Objects are. Commented Dec 7, 2011 at 10:35
  • @KaptajnKold: That is a matter of some debate in the academic circles, surprisingly. I agree that JS is capable of OOP, in that it has objects, they aren't always overly used however by some. The prototype system is a good deal different to the usual OOP flavour as well, which further removes it from the standard definition of "an OOP language". As with most languages, it depends how you use it - when I use it, it's OOP.
    – Orbling
    Commented Dec 7, 2011 at 14:38

Instead of building these into browsers, vendors like to build clunky browser plug-ins - Java, Flash, Silverlight, etc. This guarantees cross-platform consistency.

  • Well it's not about guaranteeing cross-platform consistency so much as guaranteeing control. As in you control the plugin and you don't have to answer to anyone else.
    – jhocking
    Commented Jun 21, 2011 at 22:28
  • Compared to struggling with running dirty javascript fast, "clunky" plug-ins are way better. I used to feel negatively about the whole browser-plugin download thingy, but it's definitely more open than "univerally implemented javascript".
    – Milind R
    Commented Dec 2, 2014 at 14:00

One of the reasons is that it is practically impossible for different browser vendors to even agree on a standard Javascript implementation and Javascript has been around forever, at least from a web language perspective. So most people rightfully think that getting another client side language into the ecosystem and getting all the vendors to support it is practically impossible and most of the people that could potentially make it happen are already involved in Javascript standardization issues which I think is a much better use of their time.

  • 1
    Pretty much what I was going to say. The important (in this discussion) difference between client-side and server-side languages is that browsers have to implement the client-side language.
    – jhocking
    Commented Jun 21, 2011 at 22:24

There are several responses here which claim that supporting multiple languages would make it very odious for builders of web browsers to ensure they're compliant with all the languages. To me this seems incorrect.

Java, for example is an extremely well defined standard. Essentially, all you need to do is to expose the browser DOM as a Java API, and run the Java Virtual Machine (JVM) inside your web browser. You could specify that scripting code would either have to be delivered in the form of compiled and signed JAR files, or as JavaScript sourcecode. If the browser encounters JavaScript, it could either run it through a dedicated interpreter (as it does today), or through Rhino on top of the JVM. If it encounters jar files, it creates a new class loader and security sandbox, loads the java bytecode into memory and executes it. This would be completely backward compatible with existing web pages, and would allow the browser, with a single stroke, to support the dozens of languages that run on the JVM.

Other Advantages:

  1. The JVM has benefited from a decade of performance improvements. It is now very fast, stable and mature. I’m betting you’d see a big performance improvement over interpreted javascript.
  2. As client-side apps get larger and more complex, the benefits of structured, typed languages such as Java and Scala increase.
  3. You would have access to true multi-threading, and through Scala, a collections library optimized for multi-core computing.
  4. You could use any of the thousands of open source java libraries inside the browser.
  5. Through libraries like openGL, the browser could provide access to advanced graphics and graphics-card computing capabilities.
  6. If you had java running on the client and server side, you could further benefit from client-server communications via extremely compressed, binary object-graph serialization = faster loading and performing web pages.
  • 1
    You can already run JVM code. It's called a java applet
    – Raynos
    Commented Dec 6, 2011 at 21:32

I believe JavaScript is going to gain even more ground as the standard language for the Web. We're seeing a rise in server-side JavaScript. Here are some examples of implementations of this powerful language on the server:

  • POW Web Server SJS - Server side JavaScript for the POW Web Server, which runs as a Firefox Extension or as a XULRunner Application. SJS plays a similar role to that of PHP in Apache in that it can connect to databases and generate client-side content.

  • NodeJS - Server side JavaScript that uses an event-based model. It is built using Google's V8 JavaScript Engine. NodeJS is advertised as being a tool for building scalable network programs. A "Hello World" Web server can be written in only 6 short lines!

  • Jaxer - A JavaScript server that interprets all script blocks with runat="server" as server-side JavaScript. Entire Web applications can be written in JavaScript.

  • Rhino - JavaScript for Java - Mozilla created this server-side JavaScript implementation that runs on Java. It's essentially a similar concept to Querces PHP for Java, Jython, JRuby, and many other abstractions of other languages that run on the JVM. Rhino is typically used to embed JavaScript into Java to provide scripting tools to end users, but it could also be used to move client-side code to the server without having to rewrite the business logic in another language!

  • JQuery Claypool - Server-side JavaScript framework using the power of JQuery on the server. Very cool! It's developed using the EnvJs Server-side JavaScript implementation of a browser.

  • EnvJs - A headless browser built on top of Rhino.

What many of these implementations and frameworks demonstrate is that JavaScript is becoming such a powerful force in Web development that community leaders have already started moving JavaScript to the server. JavaScript is an extremely powerful functional programming language, and as time goes on I feel we will see it evolve.

In summary, it seems like a contradiction to port the other languages to the browser when instead we can port this single browser language to the server and bridge that gap in a more unified manner.

  • +1 for pointing out that JavaScript is not confined to the browser
    – Gary
    Commented Feb 7, 2011 at 13:26

There are several examples of tools which will compile other languages to javascript, including Haskel, Lisp and Python (Probably others). So if you want to work in one of those languages you can do so.

And I think one of my professors from university wrote a scheme implementation in Javascript. So if you like scheme you can do that too.


People have worked around the lack of built-in variety in two ways: using plugins like flash or java applets, and building layers that sort of use javascript as their "machine code", like jquery or google web toolkit. If there was a new development style popular enough, people would find a way to get it in.

Just be aware if you make a .net runtime in javascript, and it ever becomes popular, certain circles will curse your name on the internet forevermore.

  • Blame webforms and IE. You'd piss of web UI devs less by jabbing them with hot pokers. Not good for brand association. Commented Oct 31, 2013 at 0:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.