3 ms·

There is just so many holes in his comparison that even if it's broadly a good point. It's lost in the details. His whole argument depends on the comparison be

by Arelius 14y ago

There is just so many holes in his comparison that even if it's broadly a good point. It's lost in the details. His whole argument depends on the comparison between Javascript and generally "Assembly" but as he argues against the label "Web Assembly" the proper comparison is from Javascript and X Assembly, where X may be X86 for instance. > If you are designing a language, compiling it to JavaScript is a pretty attractive option, for much the same reason that compiling C to machine code is an attractive option: running it in more places. No, you compile C to machine code because that is it's execution model, or perhaps because of performance. You do not "compile C to machine code to run it in more places" This however is not central to his argument. > They’re mostly backwards compatible with JavaScript Not languages compiled through the emscriptn model. > You still need to grok the DOM, or node, or whatever other platform your program is interacting with, and that’s probably documented in JavaScript. The same is true for compiled languages. The fact that they are often documented in C is just an artifact. > They break almost all of the tooling that exists for JavaScript debugging Anyone who has ever worked on a new compiled language knows that this is also problems of compile-to-asm languages. > CoffeeScript programs don’t vary any less across architectures than the JavaScript programs it creates. Again, this is true in the C->X86 ASM also. > CoffeeScript does not offer an order of magnitude difference in expressiveness This is the strongest point of his argument, but just goes to show that he takes the metaphor much too strongly, and misses the whole point of it in the first place.

Justsignedup 14y ago
The best analysis. The only thing I'd add is: There is literally no other language you can write in that will run against the following, Oh multiplex for osx, linux, windows, ios, android, symbian, and windows phone, blackberry, etc whenever possible: IE, Firefox, Opera, Safari, Chrome, Old android browser, webkit derivitives, etc. JS is the only language available everywhere so everything targets it. That's that. No other reason. Ideally a bytecode would be created with standard libraries and a browser extension and js fallback for a more efficient language that even js can be compiled to. But we have this not atm.
- KMag 14y ago
  As for your idea of compiling to some bytecode, if one wants to minimize sandboxing overhead, the representation needs to carry along with it an efficiently machine-checkable proof that it is well behaved. There are other ways to do this, but a sound static type system is the most well researched way of doing this. On top of this, the semantics of JavaScript aren't very clean, so there's a tension between making the semantics of the representation a good target for JavaScript and making the semantics of the representation a good target for non-JavaScript languages. A stack-based bytecode would likely yield the best code size (at least in the absence of compression). An SSA-based representation is most attractive from the standpoint translating to the most optimized native code. A register machine representation is a good happy medium for fast interpreters and pretty good tracing JITs. People also occasionally float the idea of shipping around compressed syntax trees to at least cut down on bandwidth usage and time taken to tokenize and parse JS, as a least disruptive option. In the end, I think there are too many options and too many players with conflicting goals for a standards committee to come up with a solution that gets widely adopted, so we'll need the invisible hand of the market to sort out the competing ideas. At present, I think the closest we've got to your ideal is LLVM bitcode via Google's PNaCl plugin. Emscripten can generate JavaScript from LLVM bitcode, closing the loop, but I'm not aware of any production systems that target PNaCl with an Emscripten fallback for browsers that don't understand PNaCl. Edit: s/space usage/bandwidth usage/, note that compressed syntax trees are the least disruptive option. Those wishing to disrupt the browser language landscape probably don't want the least disruptive option, but it's probably preferable to a lower level representation that too closely matches the semantics of JS, as that would tend to force JS semantics deeper into the VM's implementation.
  - Justsignedup 14y ago
    And that's the heart of it all. If we had a static low-level highly optimized language, im sure we'd all compile javascript or whatever to it, especially if we can add on type checking and other optimizations. HOWEVER, we cannot. That's the issue. So JS is the web's most low-level language at the moment.

by Arelius 14y ago

Justsignedup 14y ago

The best analysis. The only thing I'd add is: There is literally no other language you can write in that will run against the following, Oh multiplex for osx, linux, windows, ios, android, symbian, and windows phone, blackberry, etc whenever possible: IE, Firefox, Opera, Safari, Chrome, Old android browser, webkit derivitives, etc. JS is the only language available everywhere so everything targets it. That's that. No other reason. Ideally a bytecode would be created with standard libraries and a browser extension and js fallback for a more efficient language that even js can be compiled to. But we have this not atm.

KMag 14y ago
As for your idea of compiling to some bytecode, if one wants to minimize sandboxing overhead, the representation needs to carry along with it an efficiently machine-checkable proof that it is well behaved. There are other ways to do this, but a sound static type system is the most well researched way of doing this. On top of this, the semantics of JavaScript aren't very clean, so there's a tension between making the semantics of the representation a good target for JavaScript and making the semantics of the representation a good target for non-JavaScript languages. A stack-based bytecode would likely yield the best code size (at least in the absence of compression). An SSA-based representation is most attractive from the standpoint translating to the most optimized native code. A register machine representation is a good happy medium for fast interpreters and pretty good tracing JITs. People also occasionally float the idea of shipping around compressed syntax trees to at least cut down on bandwidth usage and time taken to tokenize and parse JS, as a least disruptive option. In the end, I think there are too many options and too many players with conflicting goals for a standards committee to come up with a solution that gets widely adopted, so we'll need the invisible hand of the market to sort out the competing ideas. At present, I think the closest we've got to your ideal is LLVM bitcode via Google's PNaCl plugin. Emscripten can generate JavaScript from LLVM bitcode, closing the loop, but I'm not aware of any production systems that target PNaCl with an Emscripten fallback for browsers that don't understand PNaCl. Edit: s/space usage/bandwidth usage/, note that compressed syntax trees are the least disruptive option. Those wishing to disrupt the browser language landscape probably don't want the least disruptive option, but it's probably preferable to a lower level representation that too closely matches the semantics of JS, as that would tend to force JS semantics deeper into the VM's implementation.
- Justsignedup 14y ago
  And that's the heart of it all. If we had a static low-level highly optimized language, im sure we'd all compile javascript or whatever to it, especially if we can add on type checking and other optimizations. HOWEVER, we cannot. That's the issue. So JS is the web's most low-level language at the moment.