5 ms·

Right, but until they're in the language spec and implemented across browsers, you can't use 64-bit integer value objects in asm.js code unless you can polyfill

Right, but until they're in the language spec and implemented across browsers, you can't use 64-bit integer value objects in asm.js code unless you can polyfill or generate asm.js code that only runs in the latest Mozilla or whatever.

BrendanEich 14y ago
So? You can't use PNaCl at all yet, and you can use NaCl only in Chrome and only loading content from the CWS. Please use the same yardstick! The cross-browser evolving standards story is the winner, not only long-term but shorter term. There is no serious argument to the contrary. /be
- NinjaWarrior 14y ago
  How about evaluating both (asm.js and PNaCl)? Looks like we are stuck in the "monoculture" you said you dislike. And this IS the reason I never love web standards. I don't like monocultures too. I feel you are biased to preserve JavaScript because you are the creator of JavaScript. IMO, asm.js might beat Flash but has a clear dead-end to beat native. We all are in a local optimum trap, I think.
  - BrendanEich 14y ago
    Do we all buy two significantly different and expensive cars to "evaluate" both? Most people can't afford to do any such thing. Nor do we all buy the same make and model of car. That's implementation monoculture. Monoculture of implementation (WebKit, which I pointed out is fragmented in practice) is not the same as a single vocabulary for each kind of language at the primitive level of the web standards layer cake. Yes, we are stuck with the web platform bottoming out at a certain set of languages. That's not monoculture, rather: termination without too much redundancy in something not so complex that multiple browsers can hope to implement interoperably. The platform has to stand on certain primitives. Remember XHTML2 vs. HTML5 back in 2005? It was going to be one or the other, even if browsers such as Firefox parsed both (but XHTML2 slowly and without incremental layout). Maybe a Microsoft or Google could have "done both" well (but IE didn't, except by treating text/xhtml as error-corrected HTML!). Without a single dominant browser vendor with enough cash and willpower to pull off more than the minimum set of semantically sufficient/complementary primitive languages, we were likely stuck with HTML/CSS/JS. SVG and MathML as HTML5 polyglot languages eventually were rationalized into the stack but still see too little use to be optimized well (and didn't Chrome turn off MathML recently?). So the primitives have to be minimized against competing browsers' ability to implement them all interoperably. Browsers weren't going to do equally well at both the 2005-era XML languages (XHTML/SVG/XSLT) and the competing incremental plan (HTML5). Arbitrary native code has been falling out as a part of the primitive layer for a while. Plugins such as Flash and Silverlight are in decline. You could say we had a plugin polyculture, but it was a security nightmare and also bad for users just in terms of updates and cross-browser/plugin UX consistency. Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors to swallow. Consider also how Dart support (2nd VM, in particular GC barriers required for cross-VM-heap cycle collection) bounced off WebKit: https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... I'm mostly being descriptive so far, but let me prescribe: Based on the hard multi-vendor specification and software engineering problems of doing well with a roughly minimized set of primitives that we have today, I do not believe it's "better" for anyone, especially for web developers, to over-extend the primitive set with things like NaCl and Pepper. That applies even if one vendor could, e.g., add SIMD primitives quickly. That just fragments the picture for developers, and misdirects some energy that could be spent on adding SIMD to JS. Same goes for Dart. It was so important to do as a "replacement" (see leaked Dash memo) and not wait for the standards bodies, but that started in 2010 (or earlier? I knew only for certain in spring 2010). It's 2013 now and Dart is not going cross browser. Things it wanted, e.g. bignums, could have been put in ES6 by now and implemented in leading JS engines. I do not agree we are in a local optimum trap, not with Unreal 3 running within 2x of native unsafe code speed. /be
    - pifflesnort 14y ago
      > Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors to swallow. You keep repeating this, but I don't see how you can be remotely serious about it. Compared to JS, DOM, HTML, and CSS, Pepper is downright simple: https://developers.google.com/native-client/peppercpp/inherits https://developers.google.com/native-client/peppercpp/inheri... As an external developer, Pepper is something I could actually implement independently for a reasonable amount of money ($2M or less) in a reasonable amount of time (1 year or less), if I could rely on Google's existing (P)NaCL toolchain. Would there be ambiguity? Yes. Google has already said they're willing to work with implementors to resolve any design or ambiguity issues. On the other hand, I can't even imagine trying to write a full browser stack, including HTML(5), CSS, JS, et al, in one year for <= $2M? Not a chance. Yet you call Pepper "too big" and "too complex". Meanwhile, the enormous weight of the mess that is the web stack creates a huge barrier to entry for anyone that might want to meaningfully contribute new ideas to the space. We're already seeing interesting development occur around (the much more approachable) NaCL/Pepper: http://zerovm.org/ http://zerovm.org/ > That just fragments the picture for developers, and misdirects some energy that could be spent on adding SIMD to JS. This is rich coming from the CTO that's refused to collaborate with Google and instead is going off and "misdirecting" energy on alternative approaches. > It's 2013 now and Dart is not going cross browser. You know, you might have something to do with that? You're not exactly a powerless or disinterested third party in this dialog.
      - tedmielczarek 14y ago
        > As an external developer, Pepper is something I could actually implement independently for a reasonable amount of money ($2M or less) in a reasonable amount of time (1 year or less), if I could rely on Google's existing (P)NaCL toolchain. But what's the point? You'd be stuck running some subset of "things that can run on the web", and the vast expanse of existing HTML content would be inaccessible. If you want to use NaCL/PNaCl for non-web applications nobody is stopping you. Writing a "browser" that doesn't implement HTML+JS is just nonsense. > Would there be ambiguity? Yes. Google has already said they're willing to work with implementors to resolve any design or ambiguity issues. We have no basis to know whether "attempt to specify all out the ambiguitity in the Pepper API, using the Chromium implementation as the standard" is harder than "implement the already-fairly-well-specified set of web technologies". We know web technologies can be implemented fairly interoperably, we have multiple interoperable implementations. > You know, you might have something to do with that? You're not exactly a powerless or disinterested third party in this dialog. And yet we're not the only game in town, either. None of the other browser manufacturers has expressed any interest, so it's not like we're alone on this. Why should we have to carry Google's banner? We've got enough stuff on our plate.
- chadaustin 14y ago
  I AM using the same yardstick (neither asm.js nor PNaCl is usable today if you want the things I listed, but I predict PNaCl will exist in some form sooner), and I'm asking you to at least talk about the merits of PNaCl. Instead of constantly beating the JavaScript drum, you could have instead said "We have tried to work with Google to standardize PNaCl without Pepper and they are not open to discussion." I know you have objections to Pepper, and I don't disagree, but personally I would be happy with a PNaCl minus Pepper too. Make WebIDL accessible from PNaCl and we can ignore all of the API issues. I have a great deal of respect for you, Brendan, and Mozilla, and this is purely a communication tone issue, but as a game developer, it frequently sounds like Mozilla is more interested in the purity of the web than actually solving developer use cases. In fact, I had a couple discussions with game developers just yesterday about the fact that it feels like Google cares more. HOWEVER, asm.js, parts of ES6/7, WebGL, etc. go a long way towards meeting the needs of game developers, so I know you actually do care about solving use cases. But you could at least be more respectful of Google's direct approach.
  - pcwalton 14y ago
    Personally, as someone who works with LLVM IR on a daily basis, the idea of standardizing LLVM IR as it exists today worries me a lot for several reasons: * Most importantly: LLVM IR is a compiler IR. http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... * LLVM IR is really big compared to asm.js. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... * LLVM IR wasn't really designed to be portable. clang bakes lots of architecture-specific stuff into the IR that it generates. It can be hacked around the way PNaCl does by trying to define a "generic" architecture, but it's stretching the architecture beyond what it was intended to do. * LLVM IR is very unstable and continually changes from version to version. If we don't care about backwards compatibility, I would much rather see a bytecode standard done from scratch than PNaCl's approach of trying to use LLVM IR. I know the reason they did it is to use LLVM's code generation backends, but I feel like that could be done without using a large underspecified compiler IR as the transport format.
  - BrendanEich 14y ago

BrendanEich 14y ago

So? You can't use PNaCl at all yet, and you can use NaCl only in Chrome and only loading content from the CWS. Please use the same yardstick! The cross-browser evolving standards story is the winner, not only long-term but shorter term. There is no serious argument to the contrary. /be

NinjaWarrior 14y ago
How about evaluating both (asm.js and PNaCl)? Looks like we are stuck in the "monoculture" you said you dislike. And this IS the reason I never love web standards. I don't like monocultures too. I feel you are biased to preserve JavaScript because you are the creator of JavaScript. IMO, asm.js might beat Flash but has a clear dead-end to beat native. We all are in a local optimum trap, I think.
- BrendanEich 14y ago
  Do we all buy two significantly different and expensive cars to "evaluate" both? Most people can't afford to do any such thing. Nor do we all buy the same make and model of car. That's implementation monoculture. Monoculture of implementation (WebKit, which I pointed out is fragmented in practice) is not the same as a single vocabulary for each kind of language at the primitive level of the web standards layer cake. Yes, we are stuck with the web platform bottoming out at a certain set of languages. That's not monoculture, rather: termination without too much redundancy in something not so complex that multiple browsers can hope to implement interoperably. The platform has to stand on certain primitives. Remember XHTML2 vs. HTML5 back in 2005? It was going to be one or the other, even if browsers such as Firefox parsed both (but XHTML2 slowly and without incremental layout). Maybe a Microsoft or Google could have "done both" well (but IE didn't, except by treating text/xhtml as error-corrected HTML!). Without a single dominant browser vendor with enough cash and willpower to pull off more than the minimum set of semantically sufficient/complementary primitive languages, we were likely stuck with HTML/CSS/JS. SVG and MathML as HTML5 polyglot languages eventually were rationalized into the stack but still see too little use to be optimized well (and didn't Chrome turn off MathML recently?). So the primitives have to be minimized against competing browsers' ability to implement them all interoperably. Browsers weren't going to do equally well at both the 2005-era XML languages (XHTML/SVG/XSLT) and the competing incremental plan (HTML5). Arbitrary native code has been falling out as a part of the primitive layer for a while. Plugins such as Flash and Silverlight are in decline. You could say we had a plugin polyculture, but it was a security nightmare and also bad for users just in terms of updates and cross-browser/plugin UX consistency. Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors to swallow. Consider also how Dart support (2nd VM, in particular GC barriers required for cross-VM-heap cycle collection) bounced off WebKit: https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... I'm mostly being descriptive so far, but let me prescribe: Based on the hard multi-vendor specification and software engineering problems of doing well with a roughly minimized set of primitives that we have today, I do not believe it's "better" for anyone, especially for web developers, to over-extend the primitive set with things like NaCl and Pepper. That applies even if one vendor could, e.g., add SIMD primitives quickly. That just fragments the picture for developers, and misdirects some energy that could be spent on adding SIMD to JS. Same goes for Dart. It was so important to do as a "replacement" (see leaked Dash memo) and not wait for the standards bodies, but that started in 2010 (or earlier? I knew only for certain in spring 2010). It's 2013 now and Dart is not going cross browser. Things it wanted, e.g. bignums, could have been put in ES6 by now and implemented in leading JS engines. I do not agree we are in a local optimum trap, not with Unreal 3 running within 2x of native unsafe code speed. /be
  - pifflesnort 14y ago
    > Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors to swallow. You keep repeating this, but I don't see how you can be remotely serious about it. Compared to JS, DOM, HTML, and CSS, Pepper is downright simple: https://developers.google.com/native-client/peppercpp/inherits https://developers.google.com/native-client/peppercpp/inheri... As an external developer, Pepper is something I could actually implement independently for a reasonable amount of money ($2M or less) in a reasonable amount of time (1 year or less), if I could rely on Google's existing (P)NaCL toolchain. Would there be ambiguity? Yes. Google has already said they're willing to work with implementors to resolve any design or ambiguity issues. On the other hand, I can't even imagine trying to write a full browser stack, including HTML(5), CSS, JS, et al, in one year for <= $2M? Not a chance. Yet you call Pepper "too big" and "too complex". Meanwhile, the enormous weight of the mess that is the web stack creates a huge barrier to entry for anyone that might want to meaningfully contribute new ideas to the space. We're already seeing interesting development occur around (the much more approachable) NaCL/Pepper: http://zerovm.org/ http://zerovm.org/ > That just fragments the picture for developers, and misdirects some energy that could be spent on adding SIMD to JS. This is rich coming from the CTO that's refused to collaborate with Google and instead is going off and "misdirecting" energy on alternative approaches. > It's 2013 now and Dart is not going cross browser. You know, you might have something to do with that? You're not exactly a powerless or disinterested third party in this dialog.
    - tedmielczarek 14y ago
      > As an external developer, Pepper is something I could actually implement independently for a reasonable amount of money ($2M or less) in a reasonable amount of time (1 year or less), if I could rely on Google's existing (P)NaCL toolchain. But what's the point? You'd be stuck running some subset of "things that can run on the web", and the vast expanse of existing HTML content would be inaccessible. If you want to use NaCL/PNaCl for non-web applications nobody is stopping you. Writing a "browser" that doesn't implement HTML+JS is just nonsense. > Would there be ambiguity? Yes. Google has already said they're willing to work with implementors to resolve any design or ambiguity issues. We have no basis to know whether "attempt to specify all out the ambiguitity in the Pepper API, using the Chromium implementation as the standard" is harder than "implement the already-fairly-well-specified set of web technologies". We know web technologies can be implemented fairly interoperably, we have multiple interoperable implementations. > You know, you might have something to do with that? You're not exactly a powerless or disinterested third party in this dialog. And yet we're not the only game in town, either. None of the other browser manufacturers has expressed any interest, so it's not like we're alone on this. Why should we have to carry Google's banner? We've got enough stuff on our plate.
chadaustin 14y ago
I AM using the same yardstick (neither asm.js nor PNaCl is usable today if you want the things I listed, but I predict PNaCl will exist in some form sooner), and I'm asking you to at least talk about the merits of PNaCl. Instead of constantly beating the JavaScript drum, you could have instead said "We have tried to work with Google to standardize PNaCl without Pepper and they are not open to discussion." I know you have objections to Pepper, and I don't disagree, but personally I would be happy with a PNaCl minus Pepper too. Make WebIDL accessible from PNaCl and we can ignore all of the API issues. I have a great deal of respect for you, Brendan, and Mozilla, and this is purely a communication tone issue, but as a game developer, it frequently sounds like Mozilla is more interested in the purity of the web than actually solving developer use cases. In fact, I had a couple discussions with game developers just yesterday about the fact that it feels like Google cares more. HOWEVER, asm.js, parts of ES6/7, WebGL, etc. go a long way towards meeting the needs of game developers, so I know you actually do care about solving use cases. But you could at least be more respectful of Google's direct approach.
- pcwalton 14y ago
  Personally, as someone who works with LLVM IR on a daily basis, the idea of standardizing LLVM IR as it exists today worries me a lot for several reasons: * Most importantly: LLVM IR is a compiler IR. http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... * LLVM IR is really big compared to asm.js. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling... * LLVM IR wasn't really designed to be portable. clang bakes lots of architecture-specific stuff into the IR that it generates. It can be hacked around the way PNaCl does by trying to define a "generic" architecture, but it's stretching the architecture beyond what it was intended to do. * LLVM IR is very unstable and continually changes from version to version. If we don't care about backwards compatibility, I would much rather see a bytecode standard done from scratch than PNaCl's approach of trying to use LLVM IR. I know the reason they did it is to use LLVM's code generation backends, but I feel like that could be done without using a large underspecified compiler IR as the transport format.
- BrendanEich 14y ago