4 ms·

Chrome was trying to do this: https://developer.chrome.com/native-client https://developer.chrome.com/native-client However, cries of foul "vendor lockin" erup

by ender7 11y ago

Chrome was trying to do this: https://developer.chrome.com/native-client https://developer.chrome.com/native-client However, cries of foul "vendor lockin" erupted. So I dunno what to tell you, man.

TazeTSchnitzel 11y ago
...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)
- 14paninta 11y ago
  asm.js doesn't support threading. it can't run native code. it doesn't support meaningful debugging. it doesn't have a post-DOM API surface like pepper.
- cwyers 11y ago
  I think you're right that they weren't trying to do this with NaCl. They really were trying to do this with Dart, though.
  - TazeTSchnitzel 11y ago
    Well, Dart would've been one other language in the browser, sure. But it's a language not that different from JavaScript in actuality. The benefits seem few for the work needed to support two different languages. Compiling to JS, which fits Dart quite well (probably because it was designed to compile to JS well), seems more productive to me. Some were excited Dart might lead to some sort of bytecode VM being added, but that didn't lead anywhere. And since then, JS has become more bytecode-like, so it doesn't really matter now anyway.
    - tosh 11y ago
      As more and more people write software in languages that compile to JavaScript instead of directly hand-writing JavaScript the demand for JavaScript becoming a better compile target grows. In that sense adoption of Dart, ClojureScript, TypeScript, Elm et all will continue to accelerate JavaScript (language and runtime) improvements.
      - BrendanEich 11y ago
        All part of the plan. I've been saying this since 2012, Dave Herman and Alon Zakai of Mozilla Research (asm.js creators along with Luke Wagner) said it before me: http://brendaneich.github.io/Strange-Loop-2012/#/21 http://brendaneich.github.io/Strange-Loop-2012/#/21 Love it when a plan comes together!
- TazeTSchnitzel 11y ago
  14paninta's comment is dead again - shadowban? Anyway, I'll repost and respond: > asm.js doesn't support threading. asm.js supports threading, actually, through Web Workers and SharedArrayBuffer. > it can't run native code. This is true, but asm.js is relatively close to the metal. It's not very far from assembly language. > it doesn't support meaningful debugging. This is a tooling issue. While the situation is bad at the moment, it'll surely improve. > it doesn't have a post-DOM API surface like pepper. Why do you need a "post-DOM API surface"? If you just want to blit stuff to the screen, the DOM is actually no less efficient than Pepper: you can directly pass it pixel buffers, or call OpenGL routines.
  - Sanddancer 11y ago
    Asm.js could be considered close to the metal if you were running on a Pentium 166. I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc. With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment. These problems all come back to the fundamental issue. There's no escape from javascript. Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility". Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web. Thus, we stagnate, and everyone suffers for it.
    - TazeTSchnitzel 11y ago
      > I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc. It has all of these things. It has SIMD now, 64-bit support is improving, IEEE-754 is supported (though some of the checks aren't available yet, I'll give you that). Give it time. > With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment. Yes, but this stuff isn't applicable to asm.js. It shares a heap between threads, it's just like your old native code, and everything is triggering race conditions^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B hunky dory. > These problems all come back to the fundamental issue. There's no escape from javascript. What's wrong with that? If you don't like JS, you can compile to it. It's an excellent compile target. > Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility". It's not just a compatibility hack, though managing to work on everything with no updates is a killer and awesome feature. It also avoids unnecessarily reinventing the wheel. It reuses as much of JS as possible. That's good. > Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web. ...well, yes, they're fracturing it. And usually needlessly. There'd be no benefit to a new language on the web. There's nothing a new language can offer which JS doesn't have. > Thus, we stagnate, and everyone suffers for it. What stagnation? Everything is moving rapidly. Things are improving all the time.
- leoc 11y ago
  > but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised None of these problems would be difficult to address if the four-member vendor cartel which controls web "standards" was willing to adopt NaCl. Of course they don't want to adopt it, but that is the real problem right there. Of the four, two members (at least—maybe now three) have an active interest in holding back the Web to protect their native app platforms, while one would rather reign in Hell (through its position of shared mastery over the Web hairball) than go broke in Heaven. As to support for other languages, I only have to point out that one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation.
  - BrendanEich 11y ago
    Nope! (On everything you wrote, including "the" and "and".) Also: loser talk is loserly. PNaCl (did you mean PNaCl not NaCl? NaCl was never proposed by Google for the Web) like Dart fell to physics. All else is stamp collecting.
    - leoc 11y ago
      So that others may judge for themselves: https://news.ycombinator.com/item?id=3092921 https://news.ycombinator.com/item?id=3092921
      - BrendanEich 11y ago
        You didn't link to any of my comments, so let me help your reading comprehension. My point then was that if Google had had MS's IE4-6-era market share and lack of scruples, they could have pushed Dart into Chrome and started using it in their web properties, and the lack of equivalent performance between DartVM and dart2js -- especially due to lack of bignums and other affordances in JS, which lack Google materially increased by choosing to invest in Dart over JS -- would have stunk. It would have verged on the monopoly abuse of which MS was in fact convicted. My point was not that JS must be the only way to run Dart simply because I or anyone at Mozilla (or anywhere else, MS and Apple included) prefers JS. That would be dumb, and it's clearly not what I wrote. Browser vendors have to keep JS improving. That's a given. Adding the extra costs of DartVM and the inter-heap GC and write barriers to glue it into the shared DOM client side is a huge tax, which would have helped kill Mozilla faster. MS and Apple wouldn't pay that tax. Why should anyone? Again it's not about JS being uncompetitive. "Competitive" is what browsers are when they run web content better and faster. Dart has very little to do with this. JS is very, very hard to replace, for reasons I summed up as "physics" (apologies to Rutherford) and won't belabor here. Yet the Dash memo proposed to do just that, to replace JS, using lame assertions about how JS couldn't be fixed. That was not just lame posturing and excuse-making for a Lars Bak retention program. Given Google's power, it was a disservice to the Web as a standards-based and ever-evolving platform, whose caretakers are obligated to keep working on it in the open, not try proprietary end-runs. (Yes, of course, many people at Google work hard to improve the Web. Good for them, but not relevant to what happened with Dash.) I'm happy to say I was wrong to worry about Google succeeding in acting like MS did with ActiveX/VBScript. Not that some at Google didn't try (or won't again with other stuff), but they failed with Dart. I predicted that, too, as an ultimate outcome after wasting years and megabucks -- including real opportunity costs to V8 and JS. So too did many at Google predict this crater. Dart's a compile-to-JS language now, not due to any preference for JS by anyone at any browser vendor. Get it yet?

by ender7 11y ago

Chrome was trying to do this: https://developer.chrome.com/native-client https://developer.chrome.com/native-client However, cries of foul "vendor lockin" erupted. So I dunno what to tell you, man.

TazeTSchnitzel 11y ago

...no they weren't? They let you embed native code (platform-specific) or LLVM IR (vendor-specific) into a webpage. I don't see what that has to do with support for other languages. Anything NaCl can do, asm.js can do too, but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised. (Hint: it's not the first one.)

14paninta 11y ago
asm.js doesn't support threading. it can't run native code. it doesn't support meaningful debugging. it doesn't have a post-DOM API surface like pepper.
cwyers 11y ago
I think you're right that they weren't trying to do this with NaCl. They really were trying to do this with Dart, though.
- TazeTSchnitzel 11y ago
  Well, Dart would've been one other language in the browser, sure. But it's a language not that different from JavaScript in actuality. The benefits seem few for the work needed to support two different languages. Compiling to JS, which fits Dart quite well (probably because it was designed to compile to JS well), seems more productive to me. Some were excited Dart might lead to some sort of bytecode VM being added, but that didn't lead anywhere. And since then, JS has become more bytecode-like, so it doesn't really matter now anyway.
  - tosh 11y ago
    As more and more people write software in languages that compile to JavaScript instead of directly hand-writing JavaScript the demand for JavaScript becoming a better compile target grows. In that sense adoption of Dart, ClojureScript, TypeScript, Elm et all will continue to accelerate JavaScript (language and runtime) improvements.
    - BrendanEich 11y ago
      All part of the plan. I've been saying this since 2012, Dave Herman and Alon Zakai of Mozilla Research (asm.js creators along with Luke Wagner) said it before me: http://brendaneich.github.io/Strange-Loop-2012/#/21 http://brendaneich.github.io/Strange-Loop-2012/#/21 Love it when a plan comes together!
TazeTSchnitzel 11y ago
14paninta's comment is dead again - shadowban? Anyway, I'll repost and respond: > asm.js doesn't support threading. asm.js supports threading, actually, through Web Workers and SharedArrayBuffer. > it can't run native code. This is true, but asm.js is relatively close to the metal. It's not very far from assembly language. > it doesn't support meaningful debugging. This is a tooling issue. While the situation is bad at the moment, it'll surely improve. > it doesn't have a post-DOM API surface like pepper. Why do you need a "post-DOM API surface"? If you just want to blit stuff to the screen, the DOM is actually no less efficient than Pepper: you can directly pass it pixel buffers, or call OpenGL routines.
- Sanddancer 11y ago
  Asm.js could be considered close to the metal if you were running on a Pentium 166. I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc. With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment. These problems all come back to the fundamental issue. There's no escape from javascript. Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility". Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web. Thus, we stagnate, and everyone suffers for it.
  - TazeTSchnitzel 11y ago
    > I'd consider it close to the metal if it had features modern processors have, like SIMD, operations on integers that have other than 32 bits, IEEE-754 compliance, etc. It has all of these things. It has SIMD now, 64-bit support is improving, IEEE-754 is supported (though some of the checks aren't available yet, I'll give you that). Give it time. > With the threading issue, Web Workers are boxed up so tightly that there are a lot of operations, like passing objects between threads, or letting web workers have access to portions of the DOM, are impossible. Additionally, because everything's passed by value, there's a lot of copying that needs to take place; to expand on my prior example, sending a message to another thread would involve copying the object to send to the main thread, then copying it again to send to the destination thread. The alternative, transferrable objects, completely deletes the object being passed, and still can't be transferred between threads. Finally, there is no pooling control among threads, which means that there is a lot less control over what threads are running at any moment. Yes, but this stuff isn't applicable to asm.js. It shares a heap between threads, it's just like your old native code, and everything is triggering race conditions^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B^B hunky dory. > These problems all come back to the fundamental issue. There's no escape from javascript. What's wrong with that? If you don't like JS, you can compile to it. It's an excellent compile target. > Asm.js is fundamentally hung off of javascript with bailing wire and duct tape, out of fear of "breaking compatibility". It's not just a compatibility hack, though managing to work on everything with no updates is a killer and awesome feature. It also avoids unnecessarily reinventing the wheel. It reuses as much of JS as possible. That's good. > Anyone that tries to experiment with a new language is immediately accused of trying to fracture the web. ...well, yes, they're fracturing it. And usually needlessly. There'd be no benefit to a new language on the web. There's nothing a new language can offer which JS doesn't have. > Thus, we stagnate, and everyone suffers for it. What stagnation? Everything is moving rapidly. Things are improving all the time.
leoc 11y ago
> but one of these has multiple implementations, is backwards-compatible, is truly cross-platform, is well-specified, and is standardised None of these problems would be difficult to address if the four-member vendor cartel which controls web "standards" was willing to adopt NaCl. Of course they don't want to adopt it, but that is the real problem right there. Of the four, two members (at least—maybe now three) have an active interest in holding back the Web to protect their native app platforms, while one would rather reign in Hell (through its position of shared mastery over the Web hairball) than go broke in Heaven. As to support for other languages, I only have to point out that one of Mozilla's reasons for decrying Google's intended browser support for Dart was that Dart compiled to JS would not be competitive with the native Dart implementation.
- BrendanEich 11y ago
  Nope! (On everything you wrote, including "the" and "and".) Also: loser talk is loserly. PNaCl (did you mean PNaCl not NaCl? NaCl was never proposed by Google for the Web) like Dart fell to physics. All else is stamp collecting.
  - leoc 11y ago
    So that others may judge for themselves: https://news.ycombinator.com/item?id=3092921 https://news.ycombinator.com/item?id=3092921
    - BrendanEich 11y ago
      You didn't link to any of my comments, so let me help your reading comprehension. My point then was that if Google had had MS's IE4-6-era market share and lack of scruples, they could have pushed Dart into Chrome and started using it in their web properties, and the lack of equivalent performance between DartVM and dart2js -- especially due to lack of bignums and other affordances in JS, which lack Google materially increased by choosing to invest in Dart over JS -- would have stunk. It would have verged on the monopoly abuse of which MS was in fact convicted. My point was not that JS must be the only way to run Dart simply because I or anyone at Mozilla (or anywhere else, MS and Apple included) prefers JS. That would be dumb, and it's clearly not what I wrote. Browser vendors have to keep JS improving. That's a given. Adding the extra costs of DartVM and the inter-heap GC and write barriers to glue it into the shared DOM client side is a huge tax, which would have helped kill Mozilla faster. MS and Apple wouldn't pay that tax. Why should anyone? Again it's not about JS being uncompetitive. "Competitive" is what browsers are when they run web content better and faster. Dart has very little to do with this. JS is very, very hard to replace, for reasons I summed up as "physics" (apologies to Rutherford) and won't belabor here. Yet the Dash memo proposed to do just that, to replace JS, using lame assertions about how JS couldn't be fixed. That was not just lame posturing and excuse-making for a Lars Bak retention program. Given Google's power, it was a disservice to the Web as a standards-based and ever-evolving platform, whose caretakers are obligated to keep working on it in the open, not try proprietary end-runs. (Yes, of course, many people at Google work hard to improve the Web. Good for them, but not relevant to what happened with Dash.) I'm happy to say I was wrong to worry about Google succeeding in acting like MS did with ActiveX/VBScript. Not that some at Google didn't try (or won't again with other stuff), but they failed with Dart. I predicted that, too, as an ultimate outcome after wasting years and megabucks -- including real opportunity costs to V8 and JS. So too did many at Google predict this crater. Dart's a compile-to-JS language now, not due to any preference for JS by anyone at any browser vendor. Get it yet?