6 ms·

What about PNaCl? What's the reason you don't support it in Mozilla? It's based on open source tools, and can be easily integrated into any browser. P.P.S. IMO

What about PNaCl? What's the reason you don't support it in Mozilla? It's based on open source tools, and can be easily integrated into any browser. P.P.S. IMO, the biggest problem about JavaScript isn't its performance. Performance is ok, and enough for the games, thanks to WebGL. The language, like many other dynamic languages, is just not very suitable for large scale development. People who write such applications, have to resort to using tools like GWT, which add substantial overhead (both in compilation time and performance). Does Mozilla has any plans to improve the situation here?

BrendanEich 13y ago
Your green-colored id says you are new here, and yet unwilling to do basic research in HN on the topic you ask about. I'll take this in the "Dear LazyWeb" spirit, assume that you are not trolling, and give some links. First, one of a few obvious searches: https://www.google.com/search?q=site:news.ycombinator.com+pnacl+mozilla+brendan https://www.google.com/search?q=site:news.ycombinator.com+pn... From the results, an entry point into a deep thread, posted by Maciej Stachowiak of Apple: https://news.ycombinator.com/item?id=4648045 https://news.ycombinator.com/item?id=4648045 Further in this sub-thread, I comment on the loaded language used to open-wash NaCl and portray critics of it as haters: https://news.ycombinator.com/item?id=4650689 https://news.ycombinator.com/item?id=4650689 Back to your comment: "It's based on open source tools" is true of Emscripten too. The bit about "can be easily integrated into any browser" is false due to Pepper, the large new target runtime for *NaCl. Pepper is a non-standard and unspecified-except-by-C++-source plugin API abstracting over both the OS and WebKit -- now Blink -- internals. To make such an airy assertion in an under-researched comment makes me suspect that you don't know that much about either PNaCl or "any browser". So why did you make that confident-sounding claim? These days, large apps are written in JS, even by hand. GWT is not growing much from what I can tell, compared to its salad days. Closure is used the most within Google, and Dart has yet to replace Google's use of GWT + Closure. Outside Google, hundreds of languages compile to JS (http://altjs.org/ http://altjs.org/). CoffeeScript is doing well still. TypeScript is Microsoft's answer to Dart, and more intentionally aligned with the evolving JS standard. "Does Mozilla has any plans to improve the situation here?" Have you heard of ES4? Mozillans including yours truly poured years into it, based on the belief that programming-in-the-large required features going back to "JS2" in 1999 (designed by Waldemar Horwat), such as classes with fixed fields and bound methods, packages, etc. Some of the particulars in ES4 didn't pan out (but could have been fixed with enough time and work). Others are very much like equivalent bits of Dart. One troublesome idea, namespaces (after Common Lisp symbol packages) could not be rescued. But ES4 failed, in part due to objections from Microsofties (one now at Mozilla) and Googlers. In a Microsoft Channel 9 interview with Lars Bak and Anders Hejlsberg, Lars and Anders both professed to like the direction of ES4 and wondered why it failed. _Quel_ irony! As always, Mozilla's plans to improve the situation involve building consensus on championed designs by one or two people, in the standards bodies, and prototyping as we specify. This is bearing fruit in ES6 and the rest of the "Harmony era" editions (ES7 is being strawman spec'ed too now; both versions have partial prototypes under way). Founding Harmony email (on the demise of ES4): https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html https://mail.mozilla.org/pipermail/es-discuss/2008-August/00... A talk I gave last fall on ES6 and beyond. http://brendaneich.github.io/Strange-Loop-2012/#/ http://brendaneich.github.io/Strange-Loop-2012/#/ For programming in the large, ES6 offers modules, classes, let, const, maps, sets, weak-maps, and many smaller affordances. I hope this helps. Even more is possible, if only the browser vendors and others invested in JS choose to keep working on evolving the language.
- solomatov 13y ago
  >To make such an airy assertion in an under-researched comment makes me suspect that you don't know that much about either PNaCl or "any browser". So why did you make that confident-sounding claim? Unfortunately, I can evaluate technologies according only to my experience and knowledge. According to my limited knowledge and experience, what PNaCl evolves to seems like the way to go: I can use whatever language I like to write code; I can utilize resources of computers efficiently; The code is performed in a sandbox; It's based on non proprietary standards (I mean LLVM, not Pepper). >The bit about "can be easily integrated into any browser" is false due to Pepper, the large new target runtime for *NaCl. Pepper is a non-standard and unspecified-except-by-C++-source plugin API abstracting over both the OS and WebKit -- now Blink -- internals. It's a new technology, how is it supposed to be standardized? IMO, it's better to create some implementation, and then, to standardize it, not vice versa. AFAIU, how Pepper API works, the application is run as a separate process, operating system APIs are isolated with Pepper API and there's a way to post JavaScript code to be executed in browser's event dispatch thread to update and query DOM. This API seems to be narrow and generic enough to be supported in any browser. Code which provides OS services can be reused from code as is, the only variable part is DOM interaction, which is narrow enough to be supported in any browser. >Have you heard of ES4? Mozillans including yours truly poured years into it, based on the belief that programming-in-the-large required features going back to "JS2" in 1999 (designed by Waldemar Horwat), such as classes with fixed fields and bound methods, packages, etc. I closely monitored what have been happening to Harmony, and it was obvious that this effort wouldn't have panned out. There were just too many complex features to be implemented (for example, generics) in a single release. >These days, large apps are written in JS, even by hand. GWT is not growing much from what I can tell, compared to its salad days. Closure is used the most within Google, and Dart has yet to replace Google's use of GWT + Closure. I myself write large scale JS apps with GWT. It's really painful but if it was written in plain JavaScript it would have been much worse (I think it event would have been impossible to write and debug code which I write). GWT has its disadvantages: compilation time is very slow, I don't have access to many APIs (mainly reflection and dynamic code loading), devmode for all browsers but Firefox is awfully slow. But despite its disadvantages, it's the best tool for my job (I debug most of the code in JVM, by abstracting away access to DOM). Both Mozilla and Google agree on goodness of LLVM, since both PNaCl, and asm.js toolchain are based on it. Google has solved the problem of efficiently representing LLVM in a platform independent way and safely executing it in a sandboxed environment. Why not create a PNaCl and LLVM based standard to allow, efficient execution of code? Is it so difficult? Mozilla promotes asm.js as a "standard compliant" way to do the same thing as PNaCl. However, there are a lot of disadvantages in this approach: asm.js is text based and very verbose, binary format will save a lot of traffic; asm.js doesn't provide access to SIMD and multi-threading which are crucial for good performance; asm.js won't work out of the box, it requiress some effort to support on the side of browser vendors, for example, the only browser where Unreal demo initially worked was Firefox nightly build. Is it so hard to find a consensus among browser vendors (or at least Mozilla and Google) in this respect?

BrendanEich 13y ago

Your green-colored id says you are new here, and yet unwilling to do basic research in HN on the topic you ask about. I'll take this in the "Dear LazyWeb" spirit, assume that you are not trolling, and give some links. First, one of a few obvious searches: https://www.google.com/search?q=site:news.ycombinator.com+pnacl+mozilla+brendan https://www.google.com/search?q=site:news.ycombinator.com+pn... From the results, an entry point into a deep thread, posted by Maciej Stachowiak of Apple: https://news.ycombinator.com/item?id=4648045 https://news.ycombinator.com/item?id=4648045 Further in this sub-thread, I comment on the loaded language used to open-wash NaCl and portray critics of it as haters: https://news.ycombinator.com/item?id=4650689 https://news.ycombinator.com/item?id=4650689 Back to your comment: "It's based on open source tools" is true of Emscripten too. The bit about "can be easily integrated into any browser" is false due to Pepper, the large new target runtime for *NaCl. Pepper is a non-standard and unspecified-except-by-C++-source plugin API abstracting over both the OS and WebKit -- now Blink -- internals. To make such an airy assertion in an under-researched comment makes me suspect that you don't know that much about either PNaCl or "any browser". So why did you make that confident-sounding claim? These days, large apps are written in JS, even by hand. GWT is not growing much from what I can tell, compared to its salad days. Closure is used the most within Google, and Dart has yet to replace Google's use of GWT + Closure. Outside Google, hundreds of languages compile to JS (http://altjs.org/ http://altjs.org/). CoffeeScript is doing well still. TypeScript is Microsoft's answer to Dart, and more intentionally aligned with the evolving JS standard. "Does Mozilla has any plans to improve the situation here?" Have you heard of ES4? Mozillans including yours truly poured years into it, based on the belief that programming-in-the-large required features going back to "JS2" in 1999 (designed by Waldemar Horwat), such as classes with fixed fields and bound methods, packages, etc. Some of the particulars in ES4 didn't pan out (but could have been fixed with enough time and work). Others are very much like equivalent bits of Dart. One troublesome idea, namespaces (after Common Lisp symbol packages) could not be rescued. But ES4 failed, in part due to objections from Microsofties (one now at Mozilla) and Googlers. In a Microsoft Channel 9 interview with Lars Bak and Anders Hejlsberg, Lars and Anders both professed to like the direction of ES4 and wondered why it failed. _Quel_ irony! As always, Mozilla's plans to improve the situation involve building consensus on championed designs by one or two people, in the standards bodies, and prototyping as we specify. This is bearing fruit in ES6 and the rest of the "Harmony era" editions (ES7 is being strawman spec'ed too now; both versions have partial prototypes under way). Founding Harmony email (on the demise of ES4): https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html https://mail.mozilla.org/pipermail/es-discuss/2008-August/00... A talk I gave last fall on ES6 and beyond. http://brendaneich.github.io/Strange-Loop-2012/#/ http://brendaneich.github.io/Strange-Loop-2012/#/ For programming in the large, ES6 offers modules, classes, let, const, maps, sets, weak-maps, and many smaller affordances. I hope this helps. Even more is possible, if only the browser vendors and others invested in JS choose to keep working on evolving the language.

solomatov 13y ago
>To make such an airy assertion in an under-researched comment makes me suspect that you don't know that much about either PNaCl or "any browser". So why did you make that confident-sounding claim? Unfortunately, I can evaluate technologies according only to my experience and knowledge. According to my limited knowledge and experience, what PNaCl evolves to seems like the way to go: I can use whatever language I like to write code; I can utilize resources of computers efficiently; The code is performed in a sandbox; It's based on non proprietary standards (I mean LLVM, not Pepper). >The bit about "can be easily integrated into any browser" is false due to Pepper, the large new target runtime for *NaCl. Pepper is a non-standard and unspecified-except-by-C++-source plugin API abstracting over both the OS and WebKit -- now Blink -- internals. It's a new technology, how is it supposed to be standardized? IMO, it's better to create some implementation, and then, to standardize it, not vice versa. AFAIU, how Pepper API works, the application is run as a separate process, operating system APIs are isolated with Pepper API and there's a way to post JavaScript code to be executed in browser's event dispatch thread to update and query DOM. This API seems to be narrow and generic enough to be supported in any browser. Code which provides OS services can be reused from code as is, the only variable part is DOM interaction, which is narrow enough to be supported in any browser. >Have you heard of ES4? Mozillans including yours truly poured years into it, based on the belief that programming-in-the-large required features going back to "JS2" in 1999 (designed by Waldemar Horwat), such as classes with fixed fields and bound methods, packages, etc. I closely monitored what have been happening to Harmony, and it was obvious that this effort wouldn't have panned out. There were just too many complex features to be implemented (for example, generics) in a single release. >These days, large apps are written in JS, even by hand. GWT is not growing much from what I can tell, compared to its salad days. Closure is used the most within Google, and Dart has yet to replace Google's use of GWT + Closure. I myself write large scale JS apps with GWT. It's really painful but if it was written in plain JavaScript it would have been much worse (I think it event would have been impossible to write and debug code which I write). GWT has its disadvantages: compilation time is very slow, I don't have access to many APIs (mainly reflection and dynamic code loading), devmode for all browsers but Firefox is awfully slow. But despite its disadvantages, it's the best tool for my job (I debug most of the code in JVM, by abstracting away access to DOM). Both Mozilla and Google agree on goodness of LLVM, since both PNaCl, and asm.js toolchain are based on it. Google has solved the problem of efficiently representing LLVM in a platform independent way and safely executing it in a sandboxed environment. Why not create a PNaCl and LLVM based standard to allow, efficient execution of code? Is it so difficult? Mozilla promotes asm.js as a "standard compliant" way to do the same thing as PNaCl. However, there are a lot of disadvantages in this approach: asm.js is text based and very verbose, binary format will save a lot of traffic; asm.js doesn't provide access to SIMD and multi-threading which are crucial for good performance; asm.js won't work out of the box, it requiress some effort to support on the side of browser vendors, for example, the only browser where Unreal demo initially worked was Firefox nightly build. Is it so hard to find a consensus among browser vendors (or at least Mozilla and Google) in this respect?