While nothing uniquely "requires' Javascript, replacing it in an existing browser is no easy feat. Look at how much work has gone into making Dart work just in Chrome.
And if any browser is going to replace Javascript, it's going to be Chrome (first), not Firefox - Mozilla is doubling-down on Javascript with both asm.js and FirefoxOS. Google is doubling-down on efforts to replace and/or subvert Javascripts, with both Dart and NaCl.
Nothing uniquely qualifies Javascript now, but being the status quo is a qualification of sorts. Replacing (or adding a second option of) a scripting language for the DOM in an existing browser is going to be tough, regardless of what the existing language is (which happens to be Javascript in all modern browsers).
Replacing (or adding a second option of) a scripting language for the DOM in an existing browser is going to be tough, regardless of what the existing language is (which happens to be Javascript in all modern browsers).
I'm not sure about that, DOM access is a bit of a mess and the js stdlib is not great either, it wouldn't be hard to improve on it. It's a real shame we've ended up in a situation where the only API for manipulating the DOM is in js - script tags were not initially intended to be js only. Switching language would be the perfect opportunity to create a proper standard library for the web, by looking at the organic mess which is DOM access, js animation, etc, extracting the good parts, and throwing away all the rest. If it significantly improved dev productivity, and was available as a plugin initially for all browsers, people might be willing to experiment with it.
There are political and technical problems with doing that of course, but it would be a great step forward for web development, and is not at all beyond the reach of a big browser vendor. I agree if it were to be anyone, it'd be Google.
> I'm not sure about that, DOM access is a bit of a mess and the js stdlib is not great either, it wouldn't be hard to improve on it
You'll get no disagreement from me about the JS stdlib. I was shocked when I found the "correct" way to extract the day of the week from a Date object in Javascript (without third-party libraries): https://stackoverflow.com/questions/4822852/javascript-how-t... [0]
It would be a great feat if/when someone does it. But saying that "Browser makers like Mozilla have had the option, at any time, to enable the use of Lisp (or any other language) in the place of Javascript" sort of ignores the amount of work required to actually do this (properly).
[0] Of course, this code does already exist internally, as evidenced by (new Date).toString(); you just can't access it.
Many languages have a great stdlib already available, all they need is an improved version of the DOM glue for events and elements (find, adjust, add). It is doable, and the vast majority of script-browser interaction is merely to find and adjust the state of some DOM elements and respond to clicks etc. You could start small and build up and still have something useful, though security and sandboxing might be the hardest issues to cover. New native platform APIs on the desktop or mobile are rewritten from the ground up regularly and those are far, far larger projects (e.g. on Mac OS Classic, Appkit, UIKit, etc).
I think the problem has not been so much that this task is incredibly difficult, but that browser vendors have very little incentive to add a new language in addition to js - it's already a money and time sink maintaining a browser, so they're not going to volunteer to make more work for themselves without a payoff for the corporation paying the bills.
I'm not sure asm.js is a bet on JavaScript, per se. It makes using other languages easier without resorting to a whole new language like Dart, or dependencies on certain platforms with NaCl.
I didn't say it was restricted to a platform, but that it depends on certain platforms, one of which is PNaCl. asm.js does not depend on the existence of such a platform, since it is backwards compatible with JavaScript.
All the API's available in JavaScript are not accessible from asm.js, you can only use asm.js for numerical code. Emscripten has to wrap all those JavaScript libraries. Pepper makes the need for wrapping obsolete, since you just call directly into the functions provided by the sandbox.
GL is easy because it requires no types. Everything that is required is included in the intersection of JavaScript and C++. More highlevel API's are harder, and that's why we don't see any wrappers for e.g. WebRTC in Emscripten.
And if any browser is going to replace Javascript, it's going to be Chrome (first), not Firefox - Mozilla is doubling-down on Javascript with both asm.js and FirefoxOS. Google is doubling-down on efforts to replace and/or subvert Javascripts, with both Dart and NaCl.
Nothing uniquely qualifies Javascript now, but being the status quo is a qualification of sorts. Replacing (or adding a second option of) a scripting language for the DOM in an existing browser is going to be tough, regardless of what the existing language is (which happens to be Javascript in all modern browsers).