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