151

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?

sawa
  • 165,429
  • 45
  • 277
  • 381
Stefano Borini
  • 138,652
  • 96
  • 297
  • 431
  • 4
    Google Dart, Script#, CoffeeScript, JSX (both different implementation of JS), JavaScript Harmony etc. See this link for more https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS – nawfal Dec 08 '12 at 23:13
  • 2
    "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?" on the server side you can install what ever you want, but i can't force your clients to install additional plugins/addons, also if we have this many bugs and security issues with javascript guess how many bugs and security issues we would have if we add a few more? – Peter Jun 02 '14 at 14:01
  • 6
    @Peter I can't tell if your argument is serious or a joke. It's trivially easy for people to install platforms if they want. If an alternative to Javascript were available and worked well, then commercial providers would just require users to download whatever is needed to run it -- just as they have always done with Flash, and as they did for a time with Silverlight. Of all the reasons why there might not emerge alternatives on the client side, the difficulty of ensuring your users have your platform is not a significant one of them. – ely Jan 13 '15 at 04:28
  • 1
    @ely: And it turned out well? Flash? Java applets? Silverlight? I did not even ever had an instance of Silverlight installed. – Sebastian Mach Mar 09 '18 at 09:19
  • @SebastianMach Yes, these third-party runtimes worked extremely well and resulted in a lot of market capture, and payoffs for their parent organizations. In fact, I would say DRM tech is probably the single most successful (from corporation viewpoint) runtime framework, and its presence is bigger now than ever, in browser and elsewhere. The other thing to consider about this line of argument is that anyone can make a browser runtime environment to manipulate DOM. It just hasn't been worth it to do this with a different language variant. Javascript merely accidentally won the land grab. – ely Mar 09 '18 at 13:16
  • @ely: Yes, the owners might be paid off by their runtimes. But did Flash pay off for the small brick and mortars? Those sites were expensive, not indexable by search engines, and nowadays often enough simply broken. When even non-IT people in my social radius complained "ugh, flash, ..., well, I'll look for another one then", then it's probably not the right tec for ye olde shoppe. – Sebastian Mach Mar 09 '18 at 17:36

18 Answers18

46

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.

Keith
  • 150,284
  • 78
  • 298
  • 434
  • 5
    I'd say it's "interpreted", not "compiled" by the browser. – Flavius Stef May 30 '09 at 22:11
  • 20
    Newer browsers do JIT compilation on the JavaScript. – Nosredna May 30 '09 at 22:13
  • Huh? JIT compilation? Not really - What the latest browsers do that makes them so fast is essentially creating underlying classes for Javascript objects (that are actually just dictionaries) and adding garbage collection. JIT refers to compiling the code into an intermediate language which is distributed - Javascript is always raw code. – Keith May 30 '09 at 22:17
  • 4
    I also googled the jit claim, and, as it turns out, Firefox 3.1 will have the support built in. Check out http://andreasgal.com/2008/08/22/tracing-the-web/ or http://people.mozilla.com/~schrep/tm-image-adjustment.swf – Flavius Stef May 30 '09 at 22:22
  • 2
    The V8 JavaScript engine (chrome) compiles directly. – Dave W. Smith May 30 '09 at 22:29
  • 1
    @Keith: Actually JIT (just-in-time) compilation refers to compiling code after distribution, on the client, into machine code. It sounds like you were trying to describe compiling to Java bytecode or MSIL. – Jay Michaud May 30 '09 at 22:35
  • @Jay Michaud - quite right, but what I'm getting at is that intermediate step. JIT compiles the IL at the last possible moment (hence the name) - i.e. on the machine the first time that the application runs. However you still have that initial 'compile' into IL. In order for Javascript to use JIT (as anything other than an internal interpretation step) you would have to get some sort of JSIL in web pages instead of the raw code. – Keith May 31 '09 at 08:22
  • "some kind of IL standard": Very good remark! One might expect that it would be possible to make such low level language (together with a foundation library) cross-OS and cross-browser. This would make it a lot easier to build web applications. – Dimitri C. Nov 18 '09 at 14:22
  • What do you mean by "IL"? Google just gives me results for "Illinois". – Ajedi32 Jun 10 '14 at 00:18
  • @Ajedi32 [Intermediate Language](http://en.wikipedia.org/wiki/Intermediate_language) – Keith Jun 13 '14 at 14:54
  • 1
    This effectively denies the premise of the question (that the OP had considered Javascript, and after considering it had decided it was a bad language, and hoped for *language* alternatives). The OP didn't say that Javascript was deficient *because of* common browser problems (different DOMs, different clients, etc.) and it is disingenuous to pretend like that's the only thing wrong here. Some people like Javascript despite its flaws. That's fine. Haskell has flaws, Python has flaws, etc. Javascript the language has many flaws. A request for alternatives deserves a reasonable answer. – ely Jan 13 '15 at 04:06
  • @Mr.F my answer was to the original question - the context appears to have been edited somewhat since then. I'll revisit this answer and add clarification. – Keith Aug 02 '15 at 12:36
  • 4
    I strongly disagree with your first answer "the problem with JavaScript is not the language itself". I think it's syntactically a very ugly language and lacks features you get from most other languages. Features that, at least I, still need in large applications (loading dependencies, *readable* OO principles). If we had to do it (internet) all over now, I don't think JavaScript would be the 'best' option for a language. – Len Jan 26 '16 at 14:39
  • 1
    @SirLenz0rlot - whether a language is 'ugly' is extremely subjective, I don't think a downvote is really fair for that. Javascript's not really an object oriented language at all, and it is specifically not designed for large applications - no wonder you personally don't like it if that's what you expect from it. As for things like loadable dependencies those are features of the framework, rather than the language syntax - anything like that needs to be parsed and executed by the browser, not the scripting language. You can't really blame Javascript for that. – Keith Jan 26 '16 at 18:03
  • @Keith It is subjective, hence "I *think*". And I think it just as subjective as "The problem is not Javascript itself", and I think, JS *is* part of the problem. Like you said yourself, Javascript is not designed for large applications. I think that just doesn't fit in the world we currently live in.(a quick compare on SO jobs search result counts: *javascript:388*, ruby:169, c++:158, php:150, java:404, c#:152, .net:128, lisp:7, ...) – Len Jan 27 '16 at 19:41
  • @SirLenz0rlot In your list Ruby, Php and List aren't designed for large applications either - popularity is not an indication of the language (or really the language + the framework, as most of these are both). Ruby is excellent for rapid prototyping, but I wouldn't try to write a game in it. C++ is what you need for high performance, but it takes a lot more time and effort to write anything. Javascript is not compiled, it is not strongly typed, it is not object oriented, all of which is fine given that it is loaded and interpreted for a single browser page and then discarded. – Keith Jan 28 '16 at 08:18
  • @SirLenz0rlot it's probably best compared to VBScript, as in old versions of IE they ran in the same way. VB script has similar syntax to VB and VB.Net, and VB.Net _is_ designed for writing large applications - VB has all the things that you complain about Javascript not having. Only _VBScript_ had to run in the browser and so was cut right down. All the things you say you don't like about Javascript are also true of VBScript - they're almost inevitable for an interpreted language running in a web browser. That leaves the syntax - and JS has Java-like syntax (as does C# and a ton of others). – Keith Jan 28 '16 at 08:25
  • Again, you said yourself, "JavaScript is not designed for large applications". Can we at least agree that in 2016, there are large applications written in JavaScript? My point is, given the current application of the internet and browsers in 2016, there are (interpretable) languages that, in my opinion would do better (for me) forlarge applications (if they were only supported by all browsers :( ) I don't think I need naming any specific ones is relevant to the discussion. – Len Jan 29 '16 at 10:08
  • "...it's a perfectly good prototyped and dynamic language." I take issue with this statement. JavaScript is a disaster of a programming language. Like PHP, it's usable and useful but that's doesn't make it "good" in any sense of the word. – Richard Eng Apr 28 '17 at 09:31
  • @RichardEng Sorry, but I disagree. JS has evolved and continues to evolve tremendously, it's a world different from PHP (which I agree with you on). Transpilation has moved a great deal too - this post is 8 years old, now I'd recommend using TypeScript if you want strong typing, but ES2017 is a very powerful language even with it's idiosyncratic typing and closures. – Keith Apr 28 '17 at 10:57
  • 1
    Just to add some info on that: yes, a javascript alternative is coming to the browsers; WebAssembly. It's meant to replace asm.js. But for now, it won't let you manipulate the dom or access browser APIs directly, you'll have to use javascript to create a bridge between the browser and WebAssembly. Allowing webAssembly to do that is planned but you better not count on it in the near future. But you'll be able to program in C/C++ etc and compile your "big" apps to WebAssembly, then run it in the browser with better size and performance. – Tiesselune Oct 24 '17 at 10:59
  • @SirLenz0rlot even in the case javascript is not ideal, it is MORE ideal than a fully object-oriented language. True OOP is very poor at working with a DOM – That Realty Programmer Guy Dec 25 '19 at 02:51
29

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.

joeytwiddle
  • 29,306
  • 13
  • 121
  • 110
  • ES6 extends Javascript with a bunch of features that allow classes to be specified more clearly, and "inline async" via generators. Still dynamically typed though! – joeytwiddle Mar 15 '15 at 20:57
  • Elm's approach is similar to Nitrogen or N2O (erlang frameworks) that's why I like it. – DenisKolodin Aug 08 '16 at 08:25
  • Nowadays we have some of CoffeeScript's syntactic sugar in ES8 and in TypeScript, as well as async-await. TypeScript has prevented a lot of bugs at my workplace, although there are still some opportunities for surprises! – joeytwiddle Sep 09 '19 at 09:24
  • There is also [Wasm](https://webassembly.org/) now, which allows various other languages to run in the browser. However communication with the DOM is still going through JavaScript. – joeytwiddle May 25 '20 at 07:21
22

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

Alex Nolasco
  • 18,750
  • 9
  • 86
  • 81
15

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.

aleemb
  • 31,265
  • 19
  • 98
  • 114
  • 1
    or MooTools, Prototype, and Dojo. http://jqueryvsmootools.com is a great comparison between mootools and jquery. – Ryan Florence May 31 '09 at 23:11
  • There is/was nothing inherently wrong with Javascript. You're likely referring to problems in IE's JScript and general rendering issues and inconsistencies with various browsers. – Gavin Jun 02 '09 at 21:09
7

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.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • 1
    +1 for using jQuery to hide browser incompatibilities. I read a book explaining how some of those mechanisms work and believe me when I say that jQuery is saving programmers headaches in this department. – Vivian River Jun 22 '11 at 14:01
  • 1
    looking at tech answers in hindsight is always a strange view. now we know the web won: silverlight, flash and air are all dead, and the remaining victor is javascript in all its weird and wonderful incantations. – oligofren Jul 07 '15 at 14:34
6

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.

sj2009
  • 454
  • 4
  • 3
5

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.

Dave W. Smith
  • 24,318
  • 4
  • 40
  • 46
4

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.

Ben Shelock
  • 20,154
  • 26
  • 92
  • 125
4

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.

Jeffrey Hantin
  • 35,734
  • 7
  • 75
  • 94
  • 1
    Don't use VBScript in IE - it's some horrible variant of VB that the big MS thought would take off but didn't. It doesn't actually work like normal VB or VBScript, and it's slower that Javascript. – Keith May 30 '09 at 22:27
  • 1
    What is lacking in, say, WebKit's or Gecko's implementations of JavaScript/ECMAScript that is available in non-browser implementations? That comment is totally confusing to me. – eyelidlessness May 31 '09 at 01:38
4

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...

Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
3

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.

CodeMonkey
  • 4,067
  • 1
  • 31
  • 43
3

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.

Alcides
  • 483
  • 3
  • 6
3

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

eyelidlessness
  • 62,413
  • 11
  • 90
  • 94
  • I mentioned GWT and Script#. For those interested in Script#, the link is http://projects.nikhilk.net/ScriptSharp/ – Nosredna May 31 '09 at 02:03
  • Thank you for pointing me to Obj-J/Cappuccino. It is amazing for creating web apps and I only opened it because you mentioned it and the name (and Cocoa-relatedness) intrigued me. – Timo Jun 07 '13 at 12:55
2

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 :)

Hannoun Yassir
  • 20,583
  • 23
  • 77
  • 112
1

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.

Nosredna
  • 83,000
  • 15
  • 95
  • 122
1

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.

Flavius Stef
  • 13,740
  • 2
  • 26
  • 22
1

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.

Karl Bartel
  • 3,244
  • 1
  • 29
  • 28
1

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.

ilya n.
  • 18,398
  • 15
  • 71
  • 89