7 ms·

Mozilla -- and Brendan Eich specifically -- have held back the web as a platform for years. Brendan Eich is myopically focused on the DOM and JavaScript monocu

Mozilla -- and Brendan Eich specifically -- have held back the web as a platform for years. Brendan Eich is myopically focused on the DOM and JavaScript monoculture -- rather than the underlying potential of the web: a standardized and completely open application platform. I assume this is due to his own vested interests and personal investment as the author of JavaScript, but it has been incredibly damaging to the web as a whole. For Google to push anything forward (NaCL, PNaCL, dart), they need at least one other major browser vendor to join them. Apple and Microsoft have vertically integrated native application markets, and have no reason to further the development of the web. That leaves Mozilla. If Mozilla genuinely cares about providing an open application platform (ala Firefox OS), they'll put Brendan Eich out to pasture and focus on moving past his stranglehold on JavaScript+HTML.

bzbarsky 14y ago
NaCL is tied to particular hardware. PNaCL doesn't exist yet, so there is nothing to push. Dart is a much more interesting question. That said, is there really value in having two and only two languages available (and leaks when you try to use both together in nontrivial ways) compared to using JavaScript as a compilation target? I guess it depends on how good a fit Dart is for your use cases...
- skatepark 14y ago
  JavaScript as a compilation target is ineffecient for both runtime and development; it's a hack. PNaCL -- and any other alternatives -- are in no small part incomplete because Eich has stated repeatedly in no uncertain terms that its JavaScript or nothing. If you want to produce an alternative, there's no chance of it being accepted. Imagine this sort of total language myopia in any other general purpose platform.
  - BrendanEich 14y ago
    Yup, I did it all -- mwah-hah-hah! I made Apple and Microsoft, iOS WebKit minions at Apple especially, even SJ, do my bidding in resisting poor pretty PNaCl. Get your tums out, pal. We're taking PNaCl down for good this year with http://asmjs.org/ http://asmjs.org/. Cross-browser. /be
    - skatepark 14y ago
      > Yup, I did it all -- mwah-hah-hah! I made Apple and Microsoft, iOS WebKit minions at Apple especially, even SJ, do my bidding in resisting poor pretty PNaCl. No, you've simply held back the only other entity interested in making the web a viable app platform: - MS and Apple, and Google's behavior are aligned with their corporate incentives. - In theory, Mozilla's behavior ought to be aligned with the interests of the web at large, but in practice, Mozilla is aligned with you, and your behavior is aligned with your own personal interest in a web platform monoculture based on your technology. Mozilla and Google, in concert, have the ability to make it a market necessity for Apple and Microsoft to follow suit. Google alone does not. This makes you the lynchpin at an organization that in theory was created for the very purpose of advancing the interests of the web. > Get your tums out, pal. We're taking PNaCl down for good this year with http://asmjs.org/ http://asmjs.org/. Cross-browser It takes a True Believer to abandon decades of research, ignore repeated market successes (in the application platform space) that vastly surpass anything they've produced, and then continue to myopically push their own invention into areas where it simply does not belong. The funny thing about asm.js is that it's an admission of the failings of standard JavaScript for this purpose, so much so that you have to define a strict subset, on top of which implementors will have to invest even more time and complex effort in providing quality implementations. This is death by a thousand cuts.
      - callahad 14y ago
        > The funny thing about asm.js is that it's an admission of the failings of standard JavaScript for this purpose, so much so that you have to define a strict subset I'm surprised you find that approach controversial. Have you not seen the awesomesauce that Re2 and PyPy bring to the table by defining strict subsets of PCRE and Python, respectively?
      - pcwalton 14y ago
        "on top of which implementors will have to invest even more time and complex effort in providing quality implementations." It is actually quite easy to implement asm.js; you just carve a "native mode" out of the VM infrastructure that already exists. Much easier than inventing a full-stack VM from scratch.
  - Shorel 14y ago
    > JavaScript as a compilation target is ineffecient for both runtime and development; it's a hack. Honestly that's only an implementation dependent detail. If there is a fast compiled Lisp like SBCL, a fast JavaScript can certainly be done.
    - skatepark 14y ago
      > Honestly that's only an implementation dependent detail. Not really, no. JavaScript is a ridiculously high-level target for another language, and this introduces a huge amount of complexity in any effort to target it efficiently. You can pare down JavaScript, as Eich seems to be banking on, but what possible technical reason is there for this? If what you care about is compatibility with Apple/MS browsers, then generate JavaScript from your intermediate bitcode/bytecode, and let those browsers be slow and complicated and have worse development tooling.
      - pcwalton 14y ago
        "If what you care about is compatibility with Apple/MS browsers, then generate JavaScript from your intermediate bitcode/bytecode" Which is precisely what the Mozilla Emscripten project does.
        skatepark 14y ago
        Emscripten doesn't treat LLVM bitcode as a first-class target, it treats it as an intermediate target to be translated into JavaScript. [high level language] -> [low level representation] -> [high level language] -> [low level representation] -> [execution] This is ridiculous to aim for as your first-order target.
  - bzbarsky 14y ago
    PNaCL is "incomplete" (as in, not working) because no one actually knows how to make it work, though they've been trying to figure it out for years. The fact that it's a hard problem has nothing to do with Brendan saying he doesn't like the idea.
azakai 14y ago
> For Google to push anything forward (NaCL, PNaCL, dart), they need at least one other major browser vendor to join them. Apple and Microsoft have vertically integrated native application markets, and have no reason to further the development of the web. That leaves Mozilla. Yes, but Mozilla still needs to be convinced that the new technology makes sense for the web. Mozilla collaborates with Google on lots of new things for the web (WebRTC, see recentl HN stories on interoperability between Chrome and Firefox there, Web Intents, etc. etc.), but it does disagree on NaCl for example.
- skatepark 14y ago
  Yes, but: Mozilla disagrees because Eich disagrees, and Eich disagrees because he's built his entire career on top of his invention of JavaScript. Is there really anyone other than Eich -- producing ANY platform -- that thinks that JavaScript is the correct baseline virtual machine to target? Breakdown of low-level targets: Google: Native, NaCL, PNaCL, Dalvik Apple: Native, LLVM (eg, for OpenGL feature emulation). MS: Native, CLR Oracle: JVM, Native Mozilla: JavaScript
  - kevingadd 14y ago
    An alternate explanation that doesn't involve a fantasy world where Brendan Eich issues oppressive decrees from his throne of skulls: Maybe Mozilla dislikes NaCL because there's actually a lot wrong with it?
    - skatepark 14y ago
      > An alternate explanation that doesn't involve a fantasy world where Brendan Eich issues oppressive decrees from his throne of skulls ... Eich is the CTO and sets the technical direction for one of the four major browsers. The browsers can only move forward standards in cooperative with one another. This isn't a fantasy world. > Maybe Mozilla dislikes NaCL because there's actually a lot wrong with it? Then maybe they could propose a solution to the problem other than adding more JavaScript? Mozilla also dislikes standardized bytecode and virtual machines: http://www.aminutewithbrendan.com/pages/20101122 http://www.aminutewithbrendan.com/pages/20101122
mwcampbell 14y ago
I think I have identified a few potentially faulty assumptions underlying your comments. You assume that the only reason that Mozilla is the only major player to push JavaScript as the way forward is that Brendan invented JS. Another interpretation which is less cynical toward Mozilla is that the other players are most interested in their own platforms, whereas Mozilla is most interested in the Web as a whole. A JavaScript runtime is the one runtime that all browsers have, so rather than fragment the landscape with a second runtime, Mozilla is pushing JS as the way forward. You assume, as if it were an axiom, that compiling other language to JavaScript is less efficient than compiling to LLVM bitcode and/or x86/ARM native code. I'll take these separately. Targeting JavaScript versus LLVM bitcode: For good performance, either of these will be JIT-compiled to native code. To claim that LLVM bitcode is a better target, you need to show that some JIT compilation technique implemented by LLVM/PNaCl is made impossible by JavaScript the language. JS typed arrays provide a C-friendly memory model; I don't know of anything else that's missing. I'd be happy to be educated though. Targeting JavaScript versus native code: Last I checked, Google is not going to push NaCl for standard web apps until PNaCl is ready. So we'll need the cross-platform target and JIT compilation anyway. You may argue that even when PNaCl is ready, application developers will also ship x86 and/or ARM builds for maximal efficiency. But let's dig a little deeper: in all likelihood, the PNaCl, x86, and ARM builds are all generated by a compiler from a single intermediate representation. In principle, why couldn't a subset of JavaScript be compiled to equally efficient native code? Even assuming that offline ahead-of-time compilation yields more efficient code than JIT compilation, a browser could observe which apps the user uses most, and apply more aggressive offline compilation to those apps. So it is by no means imperative that application developers ship native code. You also assume that Mozilla's insistence on the DOM and other existing standards, rather than PNaCl + Pepper, is unequivocally holding back the Web as an application platform. Let's drill down into specifics. What features do NaCl and Pepper provide that aren't (yet) covered by standardized APIs? My understanding was that Canvas and WebGL are helping a lot. Finally, you may be unaware of some limitations in NaCl. Specifically, because of the way NaCl validates code, you can't run a JIT compiler on top of NaCl. So, if you thought that NaCl would be a better target for Java/Python/Ruby/pick your favorite than JS, think again. For good performance, you'd need something to compile your source language to something else anyway, either JS or LLVM bitcode. Might as well be JS. I think I have demonstrated that Mozilla's insistence on JS and other standards is not holding back the Web as an application platform by any means. Indeed, none of the other major players you've mentioned, not even Google, is as serious about the Web -- the open Web -- as Mozilla.
mwcampbell 14y ago
Question for skatepark: If PNaCl were finished now and supported by every major browser, what would you do with it? Would you use it to supplement the existing web stack for performance-critical code? Or would you write whole applications in some other language (if so, which one?) and target the browser via PNaCl?
- skatepark 14y ago
  We'd also need a full widget toolkit, set of foundation/standard libraries, and all the other functionality we take for granted on other platforms. With all that in place, then I'd use whatever reasonable (JS isn't) language existed as a norm on the platform to write applications to target the browser, instead of Android, iOS, and Max OS X. My only allegiances are to user experience and the quality tooling necessary to ensure it. The web as-is provides neither.
  - mwcampbell 14y ago
    > My only allegiances are to user experience and the quality tooling necessary to ensure it. The web as-is provides neither. You assert this, but you haven't provided evidence. Web application developers are providing great user experiences. What tools do you need to provide a good user experience that the web as it is now doesn't have?
    - skatepark 14y ago
      > You assert this, but you haven't provided evidence. Web application developers are providing great user experiences. Are you serious, or are you really just that out of touch with how we work on desktop and mobile apps? > What tools do you need to provide a good user experience that the web as it is now doesn't have? - Performance, performance, performance, performance. - Performance. - The ability to use the right language for the job. The right language isn't the right language if the performance is pot, so no, Emscripten isn't a solution. I'm talking about everything from exposing SIMD intrinsics when writing time-critical software to languages that actually support compiler-checked type-safety. - Performance. - Common widget toolkits providing a common user-experience across applications, from which users can learn platform conventions and be immediately comfortable and familiar with an application. These toolkits allow us to reinventing the wheel every single time. No, bubblegum and spit collections of JavaScript and CSS are not the same thing. - Standard library which provides the functionality necessary to conform with platform exceptions and integrate with the platform. - Tools. Debuggers, compilers, and most especially, profilers and deep instrumentation. - Platform integration. This isn't just "cameras". It's also the iTunes/Media query APIs, in-app purchase, airplay, spotlight plugins, quickview plugins, menu items, and the mountain of other things that platform vendors implement to provide an integrated and coherent experience. Platform vendors push forward the user experience by providing richer platforms. Web vendors don't. - Unification of code, UI, and styling. The DOM has to go, as does CSS and JS as separate entities. It's a ridiculous model for UI development and it makes producing genuinely re-usable and interoperable component toolkits very difficult. I could probably go on all day. I WANT a non-proprietary, open, standardized application platform, but I need a platform that lets me provide the best available experience to end-users, and the web isn't it. I'm writing my software for my customers, and choosing technology over user-experience doesn't do my customers any favors.

bzbarsky 14y ago

NaCL is tied to particular hardware. PNaCL doesn't exist yet, so there is nothing to push. Dart is a much more interesting question. That said, is there really value in having two and only two languages available (and leaks when you try to use both together in nontrivial ways) compared to using JavaScript as a compilation target? I guess it depends on how good a fit Dart is for your use cases...

skatepark 14y ago
JavaScript as a compilation target is ineffecient for both runtime and development; it's a hack. PNaCL -- and any other alternatives -- are in no small part incomplete because Eich has stated repeatedly in no uncertain terms that its JavaScript or nothing. If you want to produce an alternative, there's no chance of it being accepted. Imagine this sort of total language myopia in any other general purpose platform.
- BrendanEich 14y ago
  Yup, I did it all -- mwah-hah-hah! I made Apple and Microsoft, iOS WebKit minions at Apple especially, even SJ, do my bidding in resisting poor pretty PNaCl. Get your tums out, pal. We're taking PNaCl down for good this year with http://asmjs.org/ http://asmjs.org/. Cross-browser. /be
  - skatepark 14y ago
    > Yup, I did it all -- mwah-hah-hah! I made Apple and Microsoft, iOS WebKit minions at Apple especially, even SJ, do my bidding in resisting poor pretty PNaCl. No, you've simply held back the only other entity interested in making the web a viable app platform: - MS and Apple, and Google's behavior are aligned with their corporate incentives. - In theory, Mozilla's behavior ought to be aligned with the interests of the web at large, but in practice, Mozilla is aligned with you, and your behavior is aligned with your own personal interest in a web platform monoculture based on your technology. Mozilla and Google, in concert, have the ability to make it a market necessity for Apple and Microsoft to follow suit. Google alone does not. This makes you the lynchpin at an organization that in theory was created for the very purpose of advancing the interests of the web. > Get your tums out, pal. We're taking PNaCl down for good this year with http://asmjs.org/ http://asmjs.org/. Cross-browser It takes a True Believer to abandon decades of research, ignore repeated market successes (in the application platform space) that vastly surpass anything they've produced, and then continue to myopically push their own invention into areas where it simply does not belong. The funny thing about asm.js is that it's an admission of the failings of standard JavaScript for this purpose, so much so that you have to define a strict subset, on top of which implementors will have to invest even more time and complex effort in providing quality implementations. This is death by a thousand cuts.
    - callahad 14y ago
      > The funny thing about asm.js is that it's an admission of the failings of standard JavaScript for this purpose, so much so that you have to define a strict subset I'm surprised you find that approach controversial. Have you not seen the awesomesauce that Re2 and PyPy bring to the table by defining strict subsets of PCRE and Python, respectively?
    - pcwalton 14y ago
      "on top of which implementors will have to invest even more time and complex effort in providing quality implementations." It is actually quite easy to implement asm.js; you just carve a "native mode" out of the VM infrastructure that already exists. Much easier than inventing a full-stack VM from scratch.
- Shorel 14y ago
  > JavaScript as a compilation target is ineffecient for both runtime and development; it's a hack. Honestly that's only an implementation dependent detail. If there is a fast compiled Lisp like SBCL, a fast JavaScript can certainly be done.
  - skatepark 14y ago
    > Honestly that's only an implementation dependent detail. Not really, no. JavaScript is a ridiculously high-level target for another language, and this introduces a huge amount of complexity in any effort to target it efficiently. You can pare down JavaScript, as Eich seems to be banking on, but what possible technical reason is there for this? If what you care about is compatibility with Apple/MS browsers, then generate JavaScript from your intermediate bitcode/bytecode, and let those browsers be slow and complicated and have worse development tooling.
    - pcwalton 14y ago
      "If what you care about is compatibility with Apple/MS browsers, then generate JavaScript from your intermediate bitcode/bytecode" Which is precisely what the Mozilla Emscripten project does.
      - skatepark 14y ago
        Emscripten doesn't treat LLVM bitcode as a first-class target, it treats it as an intermediate target to be translated into JavaScript. [high level language] -> [low level representation] -> [high level language] -> [low level representation] -> [execution] This is ridiculous to aim for as your first-order target.
- bzbarsky 14y ago
  PNaCL is "incomplete" (as in, not working) because no one actually knows how to make it work, though they've been trying to figure it out for years. The fact that it's a hard problem has nothing to do with Brendan saying he doesn't like the idea.

azakai 14y ago

> For Google to push anything forward (NaCL, PNaCL, dart), they need at least one other major browser vendor to join them. Apple and Microsoft have vertically integrated native application markets, and have no reason to further the development of the web. That leaves Mozilla. Yes, but Mozilla still needs to be convinced that the new technology makes sense for the web. Mozilla collaborates with Google on lots of new things for the web (WebRTC, see recentl HN stories on interoperability between Chrome and Firefox there, Web Intents, etc. etc.), but it does disagree on NaCl for example.

skatepark 14y ago
Yes, but: Mozilla disagrees because Eich disagrees, and Eich disagrees because he's built his entire career on top of his invention of JavaScript. Is there really anyone other than Eich -- producing ANY platform -- that thinks that JavaScript is the correct baseline virtual machine to target? Breakdown of low-level targets: Google: Native, NaCL, PNaCL, Dalvik Apple: Native, LLVM (eg, for OpenGL feature emulation). MS: Native, CLR Oracle: JVM, Native Mozilla: JavaScript
- kevingadd 14y ago
  An alternate explanation that doesn't involve a fantasy world where Brendan Eich issues oppressive decrees from his throne of skulls: Maybe Mozilla dislikes NaCL because there's actually a lot wrong with it?
  - skatepark 14y ago
    > An alternate explanation that doesn't involve a fantasy world where Brendan Eich issues oppressive decrees from his throne of skulls ... Eich is the CTO and sets the technical direction for one of the four major browsers. The browsers can only move forward standards in cooperative with one another. This isn't a fantasy world. > Maybe Mozilla dislikes NaCL because there's actually a lot wrong with it? Then maybe they could propose a solution to the problem other than adding more JavaScript? Mozilla also dislikes standardized bytecode and virtual machines: http://www.aminutewithbrendan.com/pages/20101122 http://www.aminutewithbrendan.com/pages/20101122

mwcampbell 14y ago

I think I have identified a few potentially faulty assumptions underlying your comments. You assume that the only reason that Mozilla is the only major player to push JavaScript as the way forward is that Brendan invented JS. Another interpretation which is less cynical toward Mozilla is that the other players are most interested in their own platforms, whereas Mozilla is most interested in the Web as a whole. A JavaScript runtime is the one runtime that all browsers have, so rather than fragment the landscape with a second runtime, Mozilla is pushing JS as the way forward. You assume, as if it were an axiom, that compiling other language to JavaScript is less efficient than compiling to LLVM bitcode and/or x86/ARM native code. I'll take these separately. Targeting JavaScript versus LLVM bitcode: For good performance, either of these will be JIT-compiled to native code. To claim that LLVM bitcode is a better target, you need to show that some JIT compilation technique implemented by LLVM/PNaCl is made impossible by JavaScript the language. JS typed arrays provide a C-friendly memory model; I don't know of anything else that's missing. I'd be happy to be educated though. Targeting JavaScript versus native code: Last I checked, Google is not going to push NaCl for standard web apps until PNaCl is ready. So we'll need the cross-platform target and JIT compilation anyway. You may argue that even when PNaCl is ready, application developers will also ship x86 and/or ARM builds for maximal efficiency. But let's dig a little deeper: in all likelihood, the PNaCl, x86, and ARM builds are all generated by a compiler from a single intermediate representation. In principle, why couldn't a subset of JavaScript be compiled to equally efficient native code? Even assuming that offline ahead-of-time compilation yields more efficient code than JIT compilation, a browser could observe which apps the user uses most, and apply more aggressive offline compilation to those apps. So it is by no means imperative that application developers ship native code. You also assume that Mozilla's insistence on the DOM and other existing standards, rather than PNaCl + Pepper, is unequivocally holding back the Web as an application platform. Let's drill down into specifics. What features do NaCl and Pepper provide that aren't (yet) covered by standardized APIs? My understanding was that Canvas and WebGL are helping a lot. Finally, you may be unaware of some limitations in NaCl. Specifically, because of the way NaCl validates code, you can't run a JIT compiler on top of NaCl. So, if you thought that NaCl would be a better target for Java/Python/Ruby/pick your favorite than JS, think again. For good performance, you'd need something to compile your source language to something else anyway, either JS or LLVM bitcode. Might as well be JS. I think I have demonstrated that Mozilla's insistence on JS and other standards is not holding back the Web as an application platform by any means. Indeed, none of the other major players you've mentioned, not even Google, is as serious about the Web -- the open Web -- as Mozilla.

mwcampbell 14y ago

Question for skatepark: If PNaCl were finished now and supported by every major browser, what would you do with it? Would you use it to supplement the existing web stack for performance-critical code? Or would you write whole applications in some other language (if so, which one?) and target the browser via PNaCl?

skatepark 14y ago
We'd also need a full widget toolkit, set of foundation/standard libraries, and all the other functionality we take for granted on other platforms. With all that in place, then I'd use whatever reasonable (JS isn't) language existed as a norm on the platform to write applications to target the browser, instead of Android, iOS, and Max OS X. My only allegiances are to user experience and the quality tooling necessary to ensure it. The web as-is provides neither.
- mwcampbell 14y ago
  > My only allegiances are to user experience and the quality tooling necessary to ensure it. The web as-is provides neither. You assert this, but you haven't provided evidence. Web application developers are providing great user experiences. What tools do you need to provide a good user experience that the web as it is now doesn't have?
  - skatepark 14y ago
    > You assert this, but you haven't provided evidence. Web application developers are providing great user experiences. Are you serious, or are you really just that out of touch with how we work on desktop and mobile apps? > What tools do you need to provide a good user experience that the web as it is now doesn't have? - Performance, performance, performance, performance. - Performance. - The ability to use the right language for the job. The right language isn't the right language if the performance is pot, so no, Emscripten isn't a solution. I'm talking about everything from exposing SIMD intrinsics when writing time-critical software to languages that actually support compiler-checked type-safety. - Performance. - Common widget toolkits providing a common user-experience across applications, from which users can learn platform conventions and be immediately comfortable and familiar with an application. These toolkits allow us to reinventing the wheel every single time. No, bubblegum and spit collections of JavaScript and CSS are not the same thing. - Standard library which provides the functionality necessary to conform with platform exceptions and integrate with the platform. - Tools. Debuggers, compilers, and most especially, profilers and deep instrumentation. - Platform integration. This isn't just "cameras". It's also the iTunes/Media query APIs, in-app purchase, airplay, spotlight plugins, quickview plugins, menu items, and the mountain of other things that platform vendors implement to provide an integrated and coherent experience. Platform vendors push forward the user experience by providing richer platforms. Web vendors don't. - Unification of code, UI, and styling. The DOM has to go, as does CSS and JS as separate entities. It's a ridiculous model for UI development and it makes producing genuinely re-usable and interoperable component toolkits very difficult. I could probably go on all day. I WANT a non-proprietary, open, standardized application platform, but I need a platform that lets me provide the best available experience to end-users, and the web isn't it. I'm writing my software for my customers, and choosing technology over user-experience doesn't do my customers any favors.