5 ms·

Except, we don't need an elegant language (and Javascript is hardly elegant, by the way). We need a virtual machine, and that's essentially what Mozilla is tryi

by sreque 14y ago

Except, we don't need an elegant language (and Javascript is hardly elegant, by the way). We need a virtual machine, and that's essentially what Mozilla is trying to define as a DSL in Javascript with asm.js. Instead, why not create something better from scratch?

BrendanEich 14y ago
Look past surface (asm.js or JS syntax) to substance. Browsers (not just Firefox) have a VM, with multiple implementations and amazing, continuously improving performance. Any from-scratch VM could be great, and I hope someone skilled (not a big company big-team effort) does one. Short of a new market-dominating browser, good luck getting such a new VM adopted and then standardized with two or more interoperable implementations cross-browser. Shortest-path evolution can get stuck, as some here fear, but JS is nowhere near stuck. Indeed JS is evolving before our eyes into a multi-language VM. asm.js and Source Maps are just a start, and we could have a bytecode syntax (or AST encoding standard, alternatively) down the road. But any clean slate work along those surface-bytecode-language lines, not to say a whole new VM, is high-risk and low-adoption (at first, and probably for a while) by definition, compared to small evolutionary jumps for JS syntax and optimized parsers and JIT'ing (and with asm.js, AOT'ing) runtimes already in the field and auto-updated in modern browsers. /be
- bennycreative 14y ago
  I'm fine with the democratization of the VM as long as they are standards-based (and compliant). If you look at the comparison of web framework performance benchmarks, they tend to group around their VM even when compared cross-VM, or comparing frameworks built on top of other frameworks which share a base VM (e.g. vert.x is about as capable as servlet in the Java VM world; ExpressJS is about as capable as Node.js (framework) in the Google V8 world). It seems to me that the VM is very important. One of JavaScript's latest, greatest triumphs has been its standardization. I care much more about -- for example -- Backbone.js's impact on code organization/standardization within an application than I do about its capability as a framework. I hope that ECMAScript 6 -- while it brings awesome new functionality to the language -- will also bring with it more backwards compatibility and standardization that these frameworks currently provide (in a somewhat fragmented, yet digestible way). And I hope the same for the democratization of the VM.
  - BrendanEich 14y ago
    With you all the way, although JS's standardization success story has been going on since 1996. I have the scars... /be

by sreque 14y ago

BrendanEich 14y ago

Look past surface (asm.js or JS syntax) to substance. Browsers (not just Firefox) have a VM, with multiple implementations and amazing, continuously improving performance. Any from-scratch VM could be great, and I hope someone skilled (not a big company big-team effort) does one. Short of a new market-dominating browser, good luck getting such a new VM adopted and then standardized with two or more interoperable implementations cross-browser. Shortest-path evolution can get stuck, as some here fear, but JS is nowhere near stuck. Indeed JS is evolving before our eyes into a multi-language VM. asm.js and Source Maps are just a start, and we could have a bytecode syntax (or AST encoding standard, alternatively) down the road. But any clean slate work along those surface-bytecode-language lines, not to say a whole new VM, is high-risk and low-adoption (at first, and probably for a while) by definition, compared to small evolutionary jumps for JS syntax and optimized parsers and JIT'ing (and with asm.js, AOT'ing) runtimes already in the field and auto-updated in modern browsers. /be

bennycreative 14y ago
I'm fine with the democratization of the VM as long as they are standards-based (and compliant). If you look at the comparison of web framework performance benchmarks, they tend to group around their VM even when compared cross-VM, or comparing frameworks built on top of other frameworks which share a base VM (e.g. vert.x is about as capable as servlet in the Java VM world; ExpressJS is about as capable as Node.js (framework) in the Google V8 world). It seems to me that the VM is very important. One of JavaScript's latest, greatest triumphs has been its standardization. I care much more about -- for example -- Backbone.js's impact on code organization/standardization within an application than I do about its capability as a framework. I hope that ECMAScript 6 -- while it brings awesome new functionality to the language -- will also bring with it more backwards compatibility and standardization that these frameworks currently provide (in a somewhat fragmented, yet digestible way). And I hope the same for the democratization of the VM.
- BrendanEich 14y ago
  With you all the way, although JS's standardization success story has been going on since 1996. I have the scars... /be