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?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

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.
–
Erik ReppenOct 31 '13 at 0:30

10 Answers
10

There is no need to add suport for multiple languages, a solution would be to standardize on a generic bytecode that could be used by language implementors. But there is 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.

+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>.
–
jmort253Feb 7 '11 at 6:26

2

@jmort253, take a look at native client.
–
dan_waterworthFeb 7 '11 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.
–
nkassisFeb 7 '11 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.
–
Jim SchubertFeb 8 '11 at 0:31

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.

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.
–
MchlFeb 10 '11 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.
–
David SergeyOct 8 '13 at 12:42

+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.
–
jmort253Feb 7 '11 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.
–
josh3736Feb 7 '11 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.
–
RyathalDec 6 '11 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).
–
Erik ReppenOct 31 '13 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.

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.
–
Matthew ScharleyFeb 7 '11 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.
–
OrblingFeb 7 '11 at 8:22

"it can be OOP"... It is OOP! Inheritance is not what defines OOP. Objects are.
–
KaptajnKoldDec 7 '11 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.
–
OrblingDec 7 '11 at 14:38

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.
–
jhockingJun 21 '11 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 RDec 2 '14 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.

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.
–
jhockingJun 21 '11 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:

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.

As client-side apps get larger and more complex, the benefits of structured, typed languages such as Java and Scala increase.

You would have access to true multi-threading, and through Scala, a collections library optimized for multi-core computing.

You could use any of the thousands of open source java libraries inside the browser.

Through libraries like openGL, the browser could provide access to advanced graphics and graphics-card computing capabilities.

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.

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.

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.

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.