I don't know but this trend of making Javascript a compilation target is making me want to shoot myself (from a compiler-design perspective). JVM->Javascript seems like they're begging me to head over to Oracle and scream "Guys! You're going the WRONG WAY!"

Javascript's absolutely ubiquitous distribution characteristics have resulted in all sorts of irrational behaviour.

If the W3C or the browser makers collectively had put some thought into making it possible for other languages to be linked into the client in a sane way (i.e. rather than the existing plugin regime), or defined some proper IL that app authors could compile to, Javascript wouldn't be on its way to being the compilation target for the web.

You make it sound like they were incompetent, lazy or evil. Or perhaps I misunderstood you, sorry if so.

But the fact is, they did think a lot about using other languages on the web, and about proper ILs as well. The fact is, there has been no good way to do either, if you want a standards-based platform with multiple compatible implementations.

You can take some existing IL like Java bytecode, but (1) that stuff is patented, and (2) there is no hope of cross-vendor agreement on what that IL should be, and all of them have various issues anyhow (for example, Java and .NET bytecode were designed with static languages in mind).

JavaScript is winning simply because it's there, it works, and everybody supports it. Yes, it has frustrating limitations, but it's hard to see a practical alternative. We will simply need to overcome those limitations - and that is possible.

That was perhaps a little harsh in the phrasing; I wasn't really implying any of those things. I think I am saying that this appears to have been a blind spot on the part of the web standardization crowd and the browser makers. Maybe I'm entirely wrong though, and there were efforts that simply hit hard problems, as you say.

I'd never heard of any discussions around determining a proper IL, though; if you can, a link so relevant MLs and such would be most appreciated.

Here's Brendan Eich (creator of JS) talking about something even simpler, a bytecode standard for JS in browsers,

http://www.aminutewithbrendan.com/pages/20101122

and here is him talking on HN about JS vs Python, Lua etc. in browsers,

http://news.ycombinator.com/item?id=1905155

Many thanks for those. I obviously haven't digested them yet, but I will.

Why do you insist on an IL? The real reason why JavaScript won out over Java and ActiveX is exactly because it's a programming language and not an IL. Inline JavaScript in HTML pages is the killer feature of JavaScript.

From a technical point of view, you also need to think about how scripts interact with other dynamically loaded scripts. That means standardizing on function calling convention, symbol tables, types and object representation. There's no way to solve these things with something like bytecode (which is why there were never any Java applets that load other Java applets), you need a dynamically-typed programming language. So R4RS Scheme may have been a better choice, but that's not what Netscape marketing wanted, so what.

Right, I just don't see the point, are people so adverse to learning a new language that they need this. I mean it is logical that higher form languages are built on top of lower level ones. But this to me seems parallel. It is not like JavaScript is a low level run-time and in fact in some ways it is easier to pick up than Java for the uninitiated.

I assume that Oracle is doing this so that people can write Java in a browser. But I don't get it, Java's efforts at being a UI language have been disastrous, both web UI and desktop.

For the same reason it make a fairly decent middleware language is the same reason that it is a poor selection for the UI. It is ridged, it trades off flexibility for safety. Which is a good thing in the middleware layer, but when it comes to writing a UI, it seems that it always has it's feet in the wrong place.

Javascript despite it's warts is a very good UI development language. I was just thinking about this the other day, when I was working on a project, I use two toolkits in my day to day work Dojo and jQuery and I was just thinking about how totally different they are and how they deal with their problem sets very well.

Dojo allows me to build up reusable widgets that are self encapsulated that can just be dropped on a page and jQuery allows me to treat the DOM almost like SQL. They are very different in their approach but yet both are built from the same building block. You just don't see that kind of diversity in Java.

Again it is for a reason, and those reasons are good in the middleware and systems integration layer, but they are cumbersome in the UI. So it makes me wonder, why people are so adverse to learning a new language that is designed for it's problem domain.

Don't shoot yourself. Think of it as a business opportunity that will pay lots of money to write compilers! That's pretty rare these days.

I'm working on a COBOL to JavaScript migration product already. $$$

If we're talking about a JVM impl (rather than a source-to-source compiler á la GWT), being able to use better languages like Clojure, Python (via Jython), Ruby (via JRuby), et al. would be a huge reason.

Fair enough. Though if you want to write code that looks like Python or Ruby, I can't recommend CoffeeScript (or Coco, if you're feeling frisky) enough.

Hmmm, I'd assumed it was a source-to-source compiler. Are they thinking of writing a JVM in JavaScript? Can you say slow? And debugging seems like a nightmare. And if it's not that, then how else does it get into the browser?

Presumably, that's what Orto did (a post about which I linked to in the original post), and apparently with reasonable performance results for the examples they provided at the time (circa 2008). Javascript runtimes are becoming absurdly fast these days, so I wouldn't put an efficient and effective JVM-in-Javascript out of reach on spec, at least not yet.

In my book, Java is the best reason not to use a JVM. It's things like Jython and Clojure that save it.

I agree; I implied that the JVM is a reason to use Java, not that Java is a reason to use the JVM.

Vast quantities of existing code?

He said other than the JVM.

> Umm...are there any reasons, other than the JVM, to use Java? I'd much rather write plain old JS (or even better, CoffeeScript) than Java any day.

Existing code. I agree that writing JavaScript is better in almost all cases, but there is a lot of existing code out there and not just in Java but C, C++, and other languages. Being able to run that on the web, anywhere, would be huge.

Yeah that just seems silly. But of course that's the Java way: add layers of abstraction wherever possible. Oh, and a big abstract IDE on top of it all would be really helpful ;-)