Alternatives to JavaScript
Solution 1:
The problem with javascript is not the language itself - it's a perfectly good prototyped and dynamic language. If you come from an OO background there's a bit of a learning curve, but it's not the language's fault.
Most people assume that Javascript is like Java because it has similar syntax and a similar name, but actually it's a lot more like lisp. It's actually pretty well suited to DOM manipulation.
The real problem is that it's compiled by the browser, and that means it works in a very different way depending on the client.
Not only is the actual DOM different depending on the browser, but there's a massive difference in performance and layout.
Edit following clarification in question
Suppose multiple interpreted languages were supported - you still have the same problems. The various browsers would still be buggy and have different DOMs.
In addition you would have to have an interpreter built into the browser or somehow installed as a plug in (that you could check for before you served up the page) for each language. It took ages to get Javascript consistent.
You can't use compiled languages in the same way - then you're introducing an executable that can't easily be scrutinised for what it does. Lots of users would choose not to let it run.
OK, so what about some sort of sandbox for the compiled code? Sounds like Java Applets to me. Or ActionScript in Flash. Or C# in Silverlight.
What about some kind of IL standard? That has more potential. Develop in whatever language you want and then compile it to IL, which the browser then JITs.
Except, Javascript is kind of already that IL - just look at GWT. It lets you write programs in Java, but distribute them as HTML and JS.
Edit following further clarification in question
Javascript isn't, or rather wasn't, the only language supported by browsers: back in the Internet Explorer dark ages you could choose between Javascript or VBScript to run in IE. Technically IE didn't even run Javascript - it ran JScript (mainly to avoid having to pay Sun for the word java, Oracle still own the name Javascript).
The problem was that VBScript was proprietary to Microsoft, but also that it just wasn't very good. While Javascript was adding functionality and getting top rate debugging tools in other browsers (like FireBug) VBScript remained IE-only and pretty much un-debuggable (dev tools in IE4/5/6 were none existent). Meanwhile VBScript also expanded to become a pretty powerful scripting tool in the OS, but none of those features were available in the browser (and when they were they became massive security holes).
There are still some corporate internal applications out there that use VBScript (and some rely on those security holes), and they're still running IE7 (they only stopped IE6 because MS finally killed it off).
Getting Javascript to it's current state has been a nightmare and has taken 20 years. It still doesn't have consistent support, with language features (specified in 1999) still missing from some browsers and lots of shims being required.
Adding an alternate language for interpreting in browsers faces two major problems:
Getting all the browser vendors to implement the new language standard - something they still haven't managed for Javascript in 20 years.
A second language potentially dilutes the support you already have, allowing (for instance) IE to have second rate Javascript support but great VBScript (again). I really don't want to be writing code in different languages for different browsers.
It should be noted that Javascript isn't 'finished' - it's still evolving to become better in new browsers. The latest version is years ahead of of the browsers' implementations and they're working on the next one.
Solution 2:
Compile to Javascript
For now, using a language which compiles to Javascript seems to be the only realistic way to reach all the platforms while writing smarter code, and this will likely remain the case for a long time. With any new offering, there will always be some reason why one or more vendors will not rush to ship it.
(But I don't really think this is a problem. Javascript has been nicely optimized by now. Machine code is also unsafe if written by hand, but works fine as a compile target and execution language.)
So many options
There is an ever growing pool of languages that compile to Javascript. A fairly comprehensive list can be found here:
- List of languages that compile to JS on the Coffeescript Wiki
Noteworthy
I will mention a few I think are noteworthy (while no doubt neglecting some gems which I am unaware of):
Spider appeared in 2016. It claims to take the best ideas of Go, Swift, Python, C# and CoffeeScript. It isn't typesafe, but it does have some minor safety features.
Elm: Haskell may be the smartest language of them all, and Elm is a variant of Haskell for Javascript. It is highly type-aware and concise, and offers Functional Reactive Programming as a neat alternative to reactive templates or MVC spaghetti. But it may be quite a shock for procedural programmers.
Google's Go is aimed at conciseness, simplicity, and safety. Go code can be compiled into Javascript by GopherJS.
Dart was Google's later attempt to replace Javascript. It offers interfaces and abstract classes through a C/Java-like syntax with optional typing.
Haxe is like Flash's ActionScript, but it can target multiple languages so your code can be re-used in Java, C, Flash, PHP and Javascript programs. It offers type-safe and dynamic objects.
Opalang adds syntactic sugar to Javascript to provide direct database access, smart continuations, type-checking and assist with client/server separation. (Tied to NodeJS and MongoDB.)
GorillaScript, "a compile-to-JavaScript language designed to empower the user while attempting to prevent some common errors." is akin to Coffeescript but more comprehensive, providing a bunch of extra features to increase safety and reduce repetitive boilerplate patterns.
LiteScript falls somewhere inbetween Coffeescript and GorillaScript. It offers async/yield syntax for "inline" callbacks, and checking for variable typos.
Microsoft's TypeScript is a small superset of Javascript that lets you place type-restrictions on function arguments, which might catch a few bugs. Similarly BetterJS allows you to apply restrictions, but in pure Javascript, either by adding extra calls or by specifying types in JSDoc comments. And now Facebook has offered Flow which additionally performs type inference.
LiveScript is a spin-off from Coffeescript that was popular for its brevity but does not look very readable to me. Probably not the best for teams.
How to choose?
When choosing an alternative language, there are some factors to consider:
If other developers join your project in future, how long will it take them to get up to speed and learn this language, or what are the chances they know it already?
Does the language have too few features (code will still be full of boilerplate) or too many features (it will take a long time to master, and until then some valid code may be undecipherable)?
Does it have the features you need for your project? (Does your project need type-checking and interfaces? Does it need smart continuations to avoid nested callback hell? Is there a lot of reactivity? Might it need to target other environments in future?)
The future...
Jeff Walker has written a thought-provoking series of blog posts about "the Javascript problem", including why he thinks neither TypeScript, nor Dart nor Coffeescript offer adequate solutions. He suggests some desirable features for an improved language in the conclusion.