In fact, lots of people said it, because it's true. Later, some folks disagreed, saying that this is an inaccurate analogy. Of course, it is inaccurate because it's an analogy. That said, as analogies go, it's pretty good. Sure, assemblers are architecture and processor specific. Maybe "JavaScript is the Web's Bytecode" is better. At the very least, JavaScript is a totally reasonable compile target.
Given that (using Wikipedia as a dictionary here and has a decent definition:
An assembly language is a low-level programming language for a computer, or other programmable device, in which there is a very strong correspondence between the language and the architecture's machine code instructions.
It's initially not clear that JavaScript is a good assembly language as it's a high-level programming language that is itself interpreted, then JIT-ted, then turned into machine instructions. Phrased differently, JavaScript floats pretty high in the stack. Certainly every processor has its own assembler and they are very specific, but the browser's JavaScript VM is what runs the "new machine code." There's only one processor architecture. The Web. (again, analogy!)
JavaScript remains a popular transpilation/compilation target. From Google's GWT to Clojure to TypeScript to CoffeeScript, it all stops at JavaScript because JavaScript is the ubiquitous virtual machine that we already have installed on our machines.
Google Native Client (NaCl) is great and will likely have a role to play, but there's only one language that works everywhere without installation or trouble and that's JavaScript.
asm.js compilation & execution pipelineWe don't all have x86 machines. We don't have have machines that we could feed assembler or C. Certainly not in a portable way. JavaScript is the great portable equalizer.
There's languages that transform to JavaScript like TypeScript and CoffeeScript and HAXE and so many more, but many of these are arguably transformations, not compilations. They also tend to compile to lots of different kinds of JavaScript.
Enter asm.js. Why not take the sprawling language that is JavaScript and pick just the subset that one would want if one were to compile something to it? Why not take the assembly-esque parts of JavaScript and formalize it? Mozilla is doing this with the clear goal to compile things to JavaScript and make it perform well. Their FAQ says they're seeing slowdowns around a factor of two, which is amazing, in case you're wondering. It's also worth noting that I, as a user, don't care if you compile your C to JavaScript. I just want a great experience on the open web, and that's another reason that targeting JavaScript moves the web forward.
Working in tandem, there's emscripten, a LLVM bitcode to JavaScript compiler. We can take C/C++ and compile it to JavaScript. Don't buy it? They ported Unreal Engine 3 in 4 days with asm.js as the target.
You can argue that JavaScript isn't the x86 or Assembly of the web. You can argue all you want. It's still happening.
Conclusion:
It's not clear that JavaScript is the end state. In fact, if anything it's clear there is no end state. But along the way we will - actually are - passing though the JavaScript as Assembler part of the trip.
Given that (using Wikipedia as a dictionary here and has a decent definition:
An assembly language is a low-level programming language for a computer, or other programmable device, in which there is a very strong correspondence between the language and the architecture's machine code instructions.
It's initially not clear that JavaScript is a good assembly language as it's a high-level programming language that is itself interpreted, then JIT-ted, then turned into machine instructions. Phrased differently, JavaScript floats pretty high in the stack. Certainly every processor has its own assembler and they are very specific, but the browser's JavaScript VM is what runs the "new machine code." There's only one processor architecture. The Web. (again, analogy!)
JavaScript remains a popular transpilation/compilation target. From Google's GWT to Clojure to TypeScript to CoffeeScript, it all stops at JavaScript because JavaScript is the ubiquitous virtual machine that we already have installed on our machines.
Google Native Client (NaCl) is great and will likely have a role to play, but there's only one language that works everywhere without installation or trouble and that's JavaScript.
asm.js compilation & execution pipelineWe don't all have x86 machines. We don't have have machines that we could feed assembler or C. Certainly not in a portable way. JavaScript is the great portable equalizer.
There's languages that transform to JavaScript like TypeScript and CoffeeScript and HAXE and so many more, but many of these are arguably transformations, not compilations. They also tend to compile to lots of different kinds of JavaScript.
Enter asm.js. Why not take the sprawling language that is JavaScript and pick just the subset that one would want if one were to compile something to it? Why not take the assembly-esque parts of JavaScript and formalize it? Mozilla is doing this with the clear goal to compile things to JavaScript and make it perform well. Their FAQ says they're seeing slowdowns around a factor of two, which is amazing, in case you're wondering. It's also worth noting that I, as a user, don't care if you compile your C to JavaScript. I just want a great experience on the open web, and that's another reason that targeting JavaScript moves the web forward.
Working in tandem, there's emscripten, a LLVM bitcode to JavaScript compiler. We can take C/C++ and compile it to JavaScript. Don't buy it? They ported Unreal Engine 3 in 4 days with asm.js as the target.
You can argue that JavaScript isn't the x86 or Assembly of the web. You can argue all you want. It's still happening.
Conclusion:
It's not clear that JavaScript is the end state. In fact, if anything it's clear there is no end state. But along the way we will - actually are - passing though the JavaScript as Assembler part of the trip.
0 comments:
Post a Comment