Mozilla is not against a bytecode VM. Mozilla (and the WebKit team minus Google) is against arbitrarily adding new language VMs because they create a major compatibility burden. Remember this:
1) JavaScript is locked in. It's too entrenched, it's never going away. Let's just accept that.
2) That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs. If you're going to support a second VM you better get it positively right. That doesn't proclude doing it, it just means it's not coming tomorrow.
> JavaScript is locked in. It's too entrenched, it's never going away. Let's just accept that.
JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language.
> That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs. If you're going to support a second VM you better get it positively right. That doesn't proclude doing it, it just means it's not coming tomorrow.
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".
> 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.
> 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.
> 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.
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?
We were actually discussing JS VM replacement in the browser, related to:
> 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.
The counter-point being that all the major browser vendors have swapped out their VM or performed significant rewrites in the past few years; it's clear that it's possible to implement a new VM and not "break the web in profound ways".
I think you are misreading that quote. It's not replacing a JS VM with another JS VM that's a problem, it's replacing a JS VM with a non-JS specific VM would cause problems and break the web (something that has been proven to happen).
Arguing that you can replace a JS VM with a JS VM doesn't help the case of replacing a JS VM with a non-JS VM.
At the surface level, I could see how your position would appear logical.
However, the nature of the replacement VM doesn't really matter in the context of what we're describing here.
The problems of compatibility remain the same regardless of whether the target VM is a JS-specific VM, or a general purpose VM; reliance on undefined behavior, accidental changes in semantics, optimization bugs, and so on.
If browser makers were able to swap-out the VM, they've already demonstrated the ability to solve the exact same kind of compatibility problems they'd face here.
A VM that provides a standardized bytecode and execution model capable of executing most modern dynamic and static turing complete languages with sufficient performance. This requires more general facilities for common functionality required; refer to tail call support, JVM's invokedynamic, etc.
Or, shorthand, a general purpose browser VM.
Unless, of course, you're arguing that the above is not truly possible, in which case I'd argue that's exactly what Google is exploring via PNaCL, and has (if not completely efficiently) been implemented across existing VMs. The PNaCL choice of LLVM bitcode was likely in error, but regardless, "no such thing" is a stretch.
Which comes full circle to my original point, which is that other than Google, nobody with a vested interest is trying, and worse yet, they actively oppose progress on this front.
> JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language.
JS running on a general VM would be slower. That's against the interests of the user.
People should stop caring what language it is. If you really don't have the skill required to use Javascript, use something easier for you and get it to compile to JS.
I've really never understood developers that bitch and whine about programming languages all day.
Adding alternate languages to the browser does absolutely nothing for the user. It would only be there to appease the "I shall only develop in lisp" extremist developers.
> JS running on a general VM would be slower. That's against the interests of the user.
What do you base this on? It's sounds like an unsupported assumption regarding the complex technical constraints involved in implementing a general purpose VM and JIT.
Putting the technical specifics aside, intuitively, why would the general VM be slower, especially since the requirement to support JavaScript would be obvious to everyone involved from day 1?
>> JS running on a general VM would be slower. That's against the interests of the user.
> What do you base this on? It's sounds like an unsupported assumption
No, he is entirely correct.
JavaScript and most dynamic languages do not run at full speed on static-language VMs like the JVM and .NET. This is despite tremendous efforts and motivation to run those languages quickly on such environments, see for example Microsoft's SPUR paper and everything it has done in the CLR to speed up dynamic languages.
The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8.
The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly. It's very difficult to do! Dynamic languages need hand-crafted PICs for example, which are extremely difficult to make portable and safe, which is necessary for a VM on the web. Also, low-level details like even how to implement numbers are significant: NaNboxing for example is used in most JS engines, but it probably doesn't make sense in a static language VM. Having both NaNboxed numbers and 'normal' ones in one VM is cumbersome and complex.
> JavaScript and most dynamic languages do not run at full speed on static-language VMs like the JVM and .NET. This is despite tremendous efforts and motivation to run those languages quickly on such environments, see for example Microsoft's SPUR paper and everything it has done in the CLR to speed up dynamic languages.
I'd argue the opposite regarding tremendous efforts and motivation; dynamic languages were an after-thought for both the JVM and .NET, and on the JVM side you've only seen any attempts to improve performance recently, with invokedynamic for Java 7.
The investments here occurred long after the VMs were developed.
> The reasons for this are technical: We do not know how to make a single VM that runs all languages quickly.
The same applies to compilers across the board; we do not know how to make a compiler that applies all possible optimization available to code always, either. I still have to manually vectorize critical paths, re-order code (sometimes in C!) to help the compiler avoid pipeline stalls, etc.
Instead, we do the best general purpose job we can, and it's usually more than fast enough.
What we're talking about here is a VM that has JS support as its first-order target. Using the JVM and CLR as performance examples here -- given what they were built for, and when -- is not particularly valid.
Speaking to NaN-boxing in particular; it's one solution to the problem, but not the only one. I'm going to remain unconvinced here, given that dynamic languages have almost always been a late, second-tier concern for anyone investing serious R&D in the development of a VM/JIT/compiler.
All that said ...
> The fact is, despite all those efforts, even Microsoft did not implement JS on .NET in IE. This despite Microsoft more than anyone having the capability and moreso the motivation ("everything on .NET"). Microsoft gave up and implemented a new JS engine in native code, and it made that new native JS VM a peer of .NET in Windows 8.
Even given the above, implementing a custom optimized JavaScript VM -- even if it was only available in JS-only case -- would not be a failure scenario.
> I'd argue the opposite regarding tremendous efforts and motivation; dynamic languages were an after-thought for both the JVM and .NET, and on the JVM side you've only seen any attempts to improve performance recently, with invokedynamic for Java 7.
> The investments here occurred long after the VMs were developed.
That's a valid point. It is possible that some entirely new kind of VM could work, that was designed from the ground up for both static and dynamic languages. But I don't think we have any good idea of such a thing!
Until we do know how to do this, replacing the JS VMs in browsers would slow everything currently running. And adding another VM alongside it would decrease speed in other ways (see for example the papers that the Apple dev mentions in the WebKit discussion for why Apple opposes adding the Dart VM into WebKit).
I'm not ready to take it as a given that we can't build a general purpose VM capable of running JS at or very near current speeds, but it's also not a solved problem.
It's not the lisp extremists that want this, it's the Python and Ruby ones. Lisp people already have plenty of options: I can think of ParenScript and ClojureScript off the top of my head. (And I'm not even (much of) a Lisp weenie. :)
> JavaScript is locked in. It's too entrenched, it's never going away. Let's just accept that
The same thing could have reasonably been said of Flash just a couple of years or so ago. It was on something like 99% of browsers.
> That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs.
Why would we need 2? Why not one VM that the additional languages AND JavaScript can all be compiled to? Then here's what you have in the browser:
1. That single VM.
2. A JavaScript compiler that compiles to that VM, so that you can still send JavaScript the traditional way as source code loaded by script tags.
Then, if someone prefers to work in Python or Ruby (or Lua, or whatever), they can compile to the byte code on the server, and send the byte code to the browser.
I'm sure that some will object that this means that if people use those other languages, then essentially they are sending binary to the browser instead of source. However, with all the hacks being done to minimize JavaScript code size, and all the machine generated JavaScript we have now, it is getting harder and harder to consider what gets sent to the client "source code" anymore for a lot of sites.
1) It will undoubtedly be slower than the current JS-quirks optimized VMs.
2) There is a shit-ton of JS on the web that has been tested to work with the current crop of VMs, moving to a new VM almost guarantees breakage. It's the same reason why GNU Screen isn't rewritten despite (supposedly) being a mess.
You're not the first person to posit that adding a new VM "almost guarantees breakage". So what? Keep the old VM, transition to the new one by specifying that's what you're targeting, then deprecate the old VM and eventually lose it altogether.
You make it sound like the computing world has never introduced a new version of a language that has implications for the older ones and managed to overcome it. Even the web did this (remember putting your scripts in comment tags?).
> You're not the first person to posit that adding a new VM "almost guarantees breakage". So what? Keep the old VM, transition to the new one by specifying that's what you're targeting, then deprecate the old VM and eventually lose it altogether.
That means both VMs will be in the browser together at some point. That is a hard problem, for example because of cross-VM garbage collection (the WebKit thread where Apple refuses to accept Dart into WebKit references some papers on that).
This will cause an immediate slowdown on existing code, and a very large maintenance burden, for example you typically need to optimize fast paths in the DOM for your VM, with two VMs that is double the work, and if the VMs are allowed to communicate - and they can, if they can both access the DOM - then you have three paths to optimize now.
It's possible to migrate from one version of a language to another - say Python 2.x to 3.x. But they are not both running in the same process and communicating directly with a third shared environment like we would have on the web.
I hate to be negative about this, because as engineers we all love technical challenges. But the fact is, it's very hard to do this stuff well. (And it's even harder to standardize it.) We need to be realistic about this: Compiling into JavaScript is the only way we will see other languages on the web for the foreseeable future.
I'm not aware of anyone disrupting critical code the way you're suggesting. It would be akin to rewriting malloc. I'm not discounting a slow transition akin to what you suggest, but you're talking about a long time frame of supporting 2 VMs side by side. Probably 10+ years.
And even then, you still have to support JavaScript being written directly in HTML <script> tags, something no other language could enjoy. So every browser must include a JavaScript to (new VM) bytecode compiler. JavaScript will always be in a priviledged position.
I do not necessarily think the web needs generic VMs to move forward, or that JS needs replacing (I happen to enjoy JS with all its quirks quite a lot).
I do, however, think that such a transition is possible if the powers that be (Google, Mozilla et. al) could agree on a fairly consistent strategy.
Yes, 2 VMs side by side would probably be needed for some time, but 10+ years? Surely pure JS VMs could be moved to plugin status and be phased out faster than that, especially since someone would just write a compiler that compiled JS to this byte code format. No, it wouldn't be as fast as a VM highly optimized for specific JS quirks, but it could probably suffice.
> It would be akin to rewriting malloc.
Custom mallocs has been written for many different purposes like for example demanding game engines. While certainly a complicated task, it has been done numerous times.
> And even then, you still have to support JavaScript being written directly in HTML <script> tags, something no other language could enjoy. So every browser must include a JavaScript to (new VM) bytecode compiler. JavaScript will always be in a priviledged position.
Why would <script> tags HAVE to contain JS? I see no reason why if we're changing to a generic byte code web, JS in <script> tags could be phased out as well.
However, as I said, I actually like JavaScript and I think experiments of modernization like Dart are approaching the "problem" in the entirely wrong way. I only think that if we "had" to change up, it could be done without much degradation to the user experience if any at all. Some old sites would break, but really, who cares? If you could compile your javascript codebase to byte code and have it still work, every one would do that without much problem.
Aside from the fact that memory allocators are written, rewritten, and tweaked all the time, your own organization's actions defang this argument: Firefox 3 included a switch to jemalloc.
A version of jemalloc specifically written for mozilla's codebase.
If it were a 100% compatible drop in replacement for malloc, why hasn't every other project switched to jemalloc yet?
(Searching for switching to jemalloc, seems like every group that tried it out found that their code base or use case exposed new problems in jemalloc. That these could be fixed doesn't negate the main point -- you couldn't just switch malloc out in existing codebases and expect everything to work right.)
I don't think I've ever seen a more dramatic real-world example of unwittingly strengthening the point you're arguing against. jemalloc didn't work quite as they wanted, so they customized it, and you really think that's a counterpoint to an argument for trying new and different things?
Ah, you're right, it's so simple! If changing the JS engine breaks a web site, the sites authors will either customize the JS engine, or choose not to switch after all!
If JavaScript never goes away and no other options are built into the web browser, the web will become irrelevant within 10-15 years.
No language lasts forever (especially not one that evolves as slowly as Javascript does), and tying the web to JavaScript and JavaScript only very obviously dooms the web. Not this year or three years from now, but eventually.
That nobody other than Google is making long-view plans for the future in this regard is somewhat insane.
Well that was basically the point I was trying to make. The web is going to have to evolve to a post-Javascript future at some point. I believe this will happen no matter how hard the JavaScript-only diehards fight against it. I'm certainly not saying the web is doomed, only that it would be if the JavaScript-only crowd really got their wish (which in the long run they won't, they can't).
1) JavaScript is locked in. It's too entrenched, it's never going away. Let's just accept that.
2) That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs. If you're going to support a second VM you better get it positively right. That doesn't proclude doing it, it just means it's not coming tomorrow.