4 ms·

> JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language. True, but the JS VMs we have today have been refined over 15+ year

> JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language. True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways. Even Google would be against dropping V8 for JS use. >There is literally zero investment in moving such an idea forward on the part of Mozilla and WebKit (sans Google). In fact, there's active resistance, while at the same time strongly favoring JavaScript as the one option. >The position more seems to be "we might chip in if someone else comes up with the perfect answer" rather than "yes, this is a problem that needs to be solved to improve developer productivity, application quality, and help the web compete with other platforms". I read the mailing list and that's not the impression I get at all. The impression I get is: 1) JavaScript still has a lot of room for improvement. Putting resources in an alternative (whatever shape that might take) distracts from improving JavaScript. 2) Most of the problems people have with JavaScript are being addressed by EmcaScript.next. 3) For those who have a general syntax/style problem, there are numerous alternatives that compile to JS to choose from, and more are likely to become popular in future as programmers from different backgrounds are compelled to write for the browser.

nupark2 15y ago
> True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways. Even Google would be against dropping V8 for JS use. And yet, Google, Apple, AND Mozilla have all successfully introduced entirely new or significantly refactored VMs in the past few years. This is solvable; it HAS been solved. > JavaScript still has a lot of room for improvement. Putting resources in an alternative (whatever shape that might take) distracts from improving JavaScript. This doesn't seem contrary to what I've stated above; it's an argument in favor of JavaScript over investing in a generic VM that would open up the ability to develop new browser languages to everyone. In that regard, failing to allow others to implement custom/experimental languages seems counterproductive to the ultimate goals you seem to be stating here. > For those who have a general syntax/style problem, there are numerous alternatives that compile to JS In terms of performance, debugging, profiling, and simple functionality, compiling to JS is simply a work-around, not a solution.
- MatthewPhillips 15y ago
  > And yet, Google, Apple, AND Mozilla have all successfully introduced entirely new or significantly refactored VMs in the past few years. Yes, because the old VMs were critically slow. Things like DOM manipulation aren't blocking problems the way they used to be. > This is solvable; it HAS been solved. Why? What critical problem requires a bytecode VM? Developers refusing to write in anything but their favorite language? > In terms of performance, debugging, profiling, and simple functionality, compiling to JS is simply a work-around, not a solution. This is solvable without alternative VMs. WebKit is working on CoffeeScript/other language debugging: http://www.infoq.com/news/2011/08/debug-languages-on-javascript-vm http://www.infoq.com/news/2011/08/debug-languages-on-javascr...
  - nupark2 15y ago
    > Why? What critical problem requires a bytecode VM? Developers refusing to write in anything but their favorite language? Your argument was that it wasn't technically achievable because it would break the web, yet it's clear that it can be done and HAS been done. I'll try to address this new argument. JS isn't perfect, it will never be perfect, and the lack of a bytecode VM is a hindrance to experiments and production language implementations that can lead to better solutions for developers. Look at the language design that has occurred elsewhere. I may not use Erlang, but I learned a lot from it. Clojure introduced a ton of interesting concurrency constructs (among other advances). C# demonstrated LINQ, and F# is OCaml revisited. In all of these cases it has nothing to do with whiny developers "refusing to write in anything but their favorite language". We're simply attempting to advance the state of the art, because nothing is perfect, especially JavaScript. > This is solvable without alternative VMs. WebKit is working on CoffeeScript/other language debugging: It's a work-around, not a solution. JavaScript still isn't an efficient bytecode format, this won't solve performance issues. We've seen similar work on languages that compile down to C, and it's not an adequate solution to debugging, especially when the debuggers benefit from language-specific enhancements.
    - jasonlotito 15y ago
      Excuse my ignorance, but what browser-based non-JS VM was introduced successfully? You mentioned this was done before, and I assume you mean it was done successfully, so just curious to know which one it is?

nupark2 15y ago

> True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways. Even Google would be against dropping V8 for JS use. And yet, Google, Apple, AND Mozilla have all successfully introduced entirely new or significantly refactored VMs in the past few years. This is solvable; it HAS been solved. > JavaScript still has a lot of room for improvement. Putting resources in an alternative (whatever shape that might take) distracts from improving JavaScript. This doesn't seem contrary to what I've stated above; it's an argument in favor of JavaScript over investing in a generic VM that would open up the ability to develop new browser languages to everyone. In that regard, failing to allow others to implement custom/experimental languages seems counterproductive to the ultimate goals you seem to be stating here. > For those who have a general syntax/style problem, there are numerous alternatives that compile to JS In terms of performance, debugging, profiling, and simple functionality, compiling to JS is simply a work-around, not a solution.

MatthewPhillips 15y ago
> And yet, Google, Apple, AND Mozilla have all successfully introduced entirely new or significantly refactored VMs in the past few years. Yes, because the old VMs were critically slow. Things like DOM manipulation aren't blocking problems the way they used to be. > This is solvable; it HAS been solved. Why? What critical problem requires a bytecode VM? Developers refusing to write in anything but their favorite language? > In terms of performance, debugging, profiling, and simple functionality, compiling to JS is simply a work-around, not a solution. This is solvable without alternative VMs. WebKit is working on CoffeeScript/other language debugging: http://www.infoq.com/news/2011/08/debug-languages-on-javascript-vm http://www.infoq.com/news/2011/08/debug-languages-on-javascr...
- nupark2 15y ago
  > Why? What critical problem requires a bytecode VM? Developers refusing to write in anything but their favorite language? Your argument was that it wasn't technically achievable because it would break the web, yet it's clear that it can be done and HAS been done. I'll try to address this new argument. JS isn't perfect, it will never be perfect, and the lack of a bytecode VM is a hindrance to experiments and production language implementations that can lead to better solutions for developers. Look at the language design that has occurred elsewhere. I may not use Erlang, but I learned a lot from it. Clojure introduced a ton of interesting concurrency constructs (among other advances). C# demonstrated LINQ, and F# is OCaml revisited. In all of these cases it has nothing to do with whiny developers "refusing to write in anything but their favorite language". We're simply attempting to advance the state of the art, because nothing is perfect, especially JavaScript. > This is solvable without alternative VMs. WebKit is working on CoffeeScript/other language debugging: It's a work-around, not a solution. JavaScript still isn't an efficient bytecode format, this won't solve performance issues. We've seen similar work on languages that compile down to C, and it's not an adequate solution to debugging, especially when the debuggers benefit from language-specific enhancements.
  - jasonlotito 15y ago
    Excuse my ignorance, but what browser-based non-JS VM was introduced successfully? You mentioned this was done before, and I assume you mean it was done successfully, so just curious to know which one it is?