6 ms·

> There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well. Not necessarily. That

by azakai 13y ago

> There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well. Not necessarily. That has been discussed at length many times here and elsewhere. PNaCl's approach is interesting and technically has much merit, but also has significant downsides (startup speed, complexity, size of implementation, reliance on LLVM for something it was not intended, risks of undefined behavior, PPAPI, etc.). It's technically an impressive technology but also one with fundamental compromises. Instead, an undeniably superior approach could be to start entirely from scratch, not JS nor LLVM nor anything else, and work to design something truly optimal for the use case we are talking about here (code shipped over the network, to run securely inside a browser, at near-native performance, with fast warm and cold startup). That would look very different from both JS and PNaCl, and could avoid the compromises that both have.

Refefer 13y ago
Most of the negatives are heavily focused on implementation rather than design, which I don't disagree with. However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. That said, as browsers act more like operating systems, it makes me wonder if we've somewhat missed the point. I agree with you about starting from scratch. I think if history is any indication, ultimately we'll end up having to write a new 'web' with very different semantics and design philosophies; goodness knows the old metaphor is starting to creak in a number of problematic ways.
- azakai 13y ago
  > However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. Not necessarily, it depends which bytecode. For example the bytecode in PNaCl, which is based on LLVM IR, is excellent for C and related languages, but not for many other important languages. Worth reading this about the limitations of LLVM IR as a bytecode: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... I've also written a post about the limitations of any single bytecode to achieve all the goals the web needs: http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
- BrendanEich 13y ago
  Java has a bytecode for its client embedding; so does Flash ActionScript. This led to trouble. From http://brendaneich.github.io/Strange-Loop-2012/#/27 http://brendaneich.github.io/Strange-Loop-2012/#/27, some pros for JS and cons for bytecode: * Dynamic typing ⇒ no verification * Type inference ⇒ delayed optimization * Would bytecode compress as well? * Bytecode standardization would suck * Bytecode versioning would suck more * Low-level bytecode is future-hostile Remember Java bytecode backward compatibility hampering language evolution, in the generics (erasure) debate and result. Then they broke bytecode compat anyway. Flash has two language implementations in it, one for AS2 and the other (Tamarin) for AS3. Only way to be sure about AS2 compat! In many ways, with JS you have one problem; add bytecode and now you have two.
  - drdaeman 13y ago
    But asm.js is a bytecode, isn't it? Just with a clever-but-weird encoding that allows a backward compatibility. In a same manner, one can deliver, for example, an x86 bytecode in JS-encoded form. Just encode opcodes as, say, "eax = 1" instead of "\xB8\x01\0\0\0".
    - BrendanEich 13y ago
      No, asm.js is a JS subset. "bytecode" as boosted here would be a non-subset, like JVML to Java source. Sure, bits is bits. Doesn't matter if you're after gzipped good results. But bytecode hopes spring eternal and the hopers do not want gzipped, minified, Emscripten-produced asm.js. They want a different syntax.
      - drdaeman 13y ago
        > No, asm.js is a JS subset. "bytecode" as boosted here would be a non-subset, like JVML to Java source. Sorry for quoting Wikipedia, but bytecode is just a form of instruction set designed for efficient execution by a software interpreter. Maybe I'm mistaken on this, but from reading about asm.js I got an impression that asm.js-aware browsers use different approach to asm.js code and treat it more like a weirdly-encoded bytecode, not as an ordirary JS source. Or I'm misunderstanding things? If so, asm.js is a bytecode. Whenever there's a correspondence between it and other languages doesn't matter for determining if it's bytecode or not, it's another (useful, but not related to being bytecode) property. > They want a different syntax. I don't think syntax matters that much, it's mostly semantics. Probably.
georgewfraser 13y ago
What about JVM, if oracle can solve the security issues. Back to the future?
- BrendanEich 13y ago
  Forget it. JS VMs in browsers are required, JVMs are dead weight. Reversing the trend against the Java plugin, which accelerated due to malware (Brian Krebs said Java was the #1 paid-for malware vector some years ago) but which began with declining plugin share re: Flash, is very unlikely. #1 reason: mobile -- plugins don't fly there, not just because Jobs was mean to Flash.

by azakai 13y ago

Refefer 13y ago

Most of the negatives are heavily focused on implementation rather than design, which I don't disagree with. However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. That said, as browsers act more like operating systems, it makes me wonder if we've somewhat missed the point. I agree with you about starting from scratch. I think if history is any indication, ultimately we'll end up having to write a new 'web' with very different semantics and design philosophies; goodness knows the old metaphor is starting to creak in a number of problematic ways.

azakai 13y ago
> However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. Not necessarily, it depends which bytecode. For example the bytecode in PNaCl, which is based on LLVM IR, is excellent for C and related languages, but not for many other important languages. Worth reading this about the limitations of LLVM IR as a bytecode: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... I've also written a post about the limitations of any single bytecode to achieve all the goals the web needs: http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
BrendanEich 13y ago
Java has a bytecode for its client embedding; so does Flash ActionScript. This led to trouble. From http://brendaneich.github.io/Strange-Loop-2012/#/27 http://brendaneich.github.io/Strange-Loop-2012/#/27, some pros for JS and cons for bytecode: * Dynamic typing ⇒ no verification * Type inference ⇒ delayed optimization * Would bytecode compress as well? * Bytecode standardization would suck * Bytecode versioning would suck more * Low-level bytecode is future-hostile Remember Java bytecode backward compatibility hampering language evolution, in the generics (erasure) debate and result. Then they broke bytecode compat anyway. Flash has two language implementations in it, one for AS2 and the other (Tamarin) for AS3. Only way to be sure about AS2 compat! In many ways, with JS you have one problem; add bytecode and now you have two.
- drdaeman 13y ago
  But asm.js is a bytecode, isn't it? Just with a clever-but-weird encoding that allows a backward compatibility. In a same manner, one can deliver, for example, an x86 bytecode in JS-encoded form. Just encode opcodes as, say, "eax = 1" instead of "\xB8\x01\0\0\0".
  - BrendanEich 13y ago
    No, asm.js is a JS subset. "bytecode" as boosted here would be a non-subset, like JVML to Java source. Sure, bits is bits. Doesn't matter if you're after gzipped good results. But bytecode hopes spring eternal and the hopers do not want gzipped, minified, Emscripten-produced asm.js. They want a different syntax.
    - drdaeman 13y ago
      > No, asm.js is a JS subset. "bytecode" as boosted here would be a non-subset, like JVML to Java source. Sorry for quoting Wikipedia, but bytecode is just a form of instruction set designed for efficient execution by a software interpreter. Maybe I'm mistaken on this, but from reading about asm.js I got an impression that asm.js-aware browsers use different approach to asm.js code and treat it more like a weirdly-encoded bytecode, not as an ordirary JS source. Or I'm misunderstanding things? If so, asm.js is a bytecode. Whenever there's a correspondence between it and other languages doesn't matter for determining if it's bytecode or not, it's another (useful, but not related to being bytecode) property. > They want a different syntax. I don't think syntax matters that much, it's mostly semantics. Probably.

georgewfraser 13y ago

What about JVM, if oracle can solve the security issues. Back to the future?

BrendanEich 13y ago
Forget it. JS VMs in browsers are required, JVMs are dead weight. Reversing the trend against the Java plugin, which accelerated due to malware (Brian Krebs said Java was the #1 paid-for malware vector some years ago) but which began with declining plugin share re: Flash, is very unlikely. #1 reason: mobile -- plugins don't fly there, not just because Jobs was mean to Flash.