Alternatives to JavaScript

Question

At the moment, the only fully supported language, and the de-facto standard for DOM tree manipulation in the browser is JavaScript. It looks like it has deep design issues t

Answer 1

One thing I haven't seen mentioned (oh, I see Alcides mentioned HotRuby while I was writing and Nosredna mentioned GWT and Script#) and would like to throw out there is there are a number of implementations of [insert language]-on-JavaScript (eg. translators that allow you to convert Ruby, Python, C#, Java, Obj-J/Cappuccino [similar to Obj-C/Cocoa] or Processing [for Canvas] to JavaScript either on the client or before deployment [and some of which also feature various abstraction libraries]). Of course there's a performance overhead if it is being translated on the client, but if you are more comfortable with another language it will allow you some flexibility.

Personally, though, I recommend learning to love JavaScript. It's an excellent, powerful language, and pretty elegant once you get to know it. I'm facing the opposite dilemma, chomping at the bit to have a capable server-side JavaScript/DOM solution that meets all of my needs. /unsolicited opinion

Answer 2

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.

Answer 3

Doug Crockford gave a talk to Google detailing the bad and good parts of JavaScript and its future. It actually hasn't changed much at all since 1999--which can be said to be a good thing (pretty much all browsers can run the same code as long as you're aware of their limitations) and Doug shows where the good parts were mostly misunderstandings that turn out to be very powerful.

For DOM manipuluation, look at JQuery as a client-side library that replaces most of the awful DOM API with operations that are a pain to write to pretty elegant bits of code that are easier to write.

Answer 4

As already said, you have Flash (ActionScript, which is a derived language from Javascript) and Silverlight/Moonlight (IronPython, IronRuby, JScript, VBScript, C#) that can run in the browser via plugins (the first one being much more ubiquitous).

There is also another alternative if you like Ruby: HotRuby, it's a ruby implementation in javascript that will run in the browser. It is not very mature yet, but you can have a look at it.

Answer 5

JavaScript is the English language of the web. English historically spread because it had a strong navy conquering various countries. This is comparable to big companies that conquered the web with JavaScript. It's a language clobbered together from multiple European sources (Greek, Latin, Germanic languages, French even some Chinese and Indian words). JavaScript borrowed a lot of concepts throughout the years from other languages (structural, OO, functional). English is spoken in different places with slight variations in dialect and accent, that can render understanding difficult. Just like JavaScript has different browsers interpreting it a bit differently.

Even though English is easy to learn initially, it has very inconsistent pronunciation and more exceptions than rules. Just like JavaScript it's always there to offer a surprise.

Despite the different accents, JavaScript is the lingua franca of the web. Just like you might not be English and write here in English, every web browser has a certain degree of English understanding. IE6 is like the guy who says on his resume that he's fluent, but only went to a two week course on English as a foreign language.

There have been attempts to supplant English as the worlds main language, e.g. Esperanto. But all of them failed, because most people on earth speak some English. In the same way it will be difficult to introduce better alternatives to JavaScript.

Answer 6

If you're thinking that JavaScript has deep issues, I recommend Doug Crockford's book, JavaScript: The Good Parts. (Or Google for "Crockford JavaScript" to find several video presentations he's done.) Crockford sketches out a safe subset and set of practices, and specifically lists some parts of the language to avoid.

I'm unaware of plans to replace JavaScript as the de facto means of manipulating the DOM. So best learn to use it safely and well.