Alternatives to JavaScript

StackOverflow https://stackoverflow.com/questions/930716

  •  06-09-2019
  •  | 
  •  

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 that make it a minefield of bugs and security holes for the novice.

Do you know of any existent or planned initiative to introduce a better (redesigned) language of any kind (not only javascript) for DOM tree manipulation and HTTP requests in next generation browsers? If yes, what is the roadmap for its integration into, say, Firefox, and if no, for what reasons (apart of interoperability) should be JavaScript the only supported language on the browser platform?

I already used jQuery and I also read "javascript: the good parts". Indeed the suggestions are good, but what I am not able to understand is: why only javascript? On the server-side (your-favourite-os platform), we can manipulate a DOM tree with every language, even fortran. Why does the client side (the browser platform) support only javascript?

Was it helpful?

Solution

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.

OTHER TIPS

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:

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.

should be JavaScript the only supported language on the browser platform ?

Yes and no. There is an alternative out there called Dart by Google which does compile to JavaScript and just like jQuery it tries to make DOM manipulation a bit easier. It may be fun to experiment, check it out.

See also

It is true that Javascript was at one point notoriously hard to deal with but the web development community has come a long way since. Instead, I would encourage you to have a look at jQuery. It's easy and abstracts away all the various problems.

And there really are no alternatives that work across the board. Flash comes to mind but that too is ECMA script and it's probably over kill for most things.

Short term, I'd use things like jQuery to hide the browser incompatibilities. Long term, technologies like Silverlight or Adobe AIR may make this a very different minefield (but still a minefield) in the future.

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.

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.

In terms of client side Javascript is the only way to manipulate the DOM. In terms of server side there are a multitude of ways.

Internet Explorer supports pluggable scripting languages, although the only one reliably included with IE besides JScript is VBScript.

As far as I have seen, there seems to be a general sort of bias toward dynamic languages in the browser, and JavaScript seems to fill this need adequately enough that network effects make any other language a non-starter. The language is actually quite powerful, though its implementation in browsers leaves much to be desired.

If you're willing to restrict your customers/visitors to specific browsers, and possibly willing to require them to install a plug-in, you could look at MS Silverlight -- a readable overview is on wikipedia. With Silverlight 2, you can run, client-side, code you've written in C#, IronPython, IronRuby, VB.NET, etc; the free Moonlight clone of Silverlight, from the Mono project, promises to bring the same functionality to Linux.

In practice, most developers of web apps and sites prefer to reach wider audiences than Silverlight (and eventually Moonlight) can currently deliver -- which means sticking with Javascript, or possibly Flash (which uses a similar programming language, Actionscript).

So, gaining substantial mindshare, adoption and traction for anything else is proving to be an uphill fight even for Microsoft with its large groups of engineers and marketing budgets and a free-software project on the side (to possibly ease worries about proprietary lock-in) -- which may help explain why there's very little interest, e.g. on the part of the Mozilla Foundation, in pushing towards such a goal. "Apart from interoperability", you say: but clearly the issue of interoperability is THE biggie here, given what we observe wrt Silverlight's progress...

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.

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

No. JavaScript is it, but it will evolve. The next version is "JavaScript Harmony," and you can learn more if you Google that.

Now and then someone suggests putting a byte code interpreter into the browsers alongside JavaScript. Probably won't happen, at least for awhile.

I happen to love JavaScript. But there are other solutions, including GWT, which compiles Java to JavaScript and Script#, which compiles C# to JavaScript.

Jquery (still javascript but) it will really help you they have support for almost all the browsers and it isn't really that hard to learn :)

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.

I don't think Javascript will be replaced any time soon. For a completely different approach to rich clients, you might want to investigate Flex, which is a Flash-based technology.

Maybe something like haxe (see haxe.org) could help you. It is a language which seems cleaner than JavaScript and can be compiled down to JavaScript, so it can be run inside a browser.

I know that this is not a direct answer to your question, but I thought it might be interesting for you, nevertheless.

Many people understand that Javascript isn't best and prettiest language ever. However, it is currently supported by browsers, and thus it will be extremely hard to introduce a different language. We simply don't need another browser war.

This explains why I know of no plans of switching to a different client-side language.

But I think Javascript isn't so bad if you start thinking about DOM model and how would one work with it. Many things that are messy with JS are the result of the way DOM model works.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top